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本 书 从 消息 中 间 件 的 概念 和 RabbitMQ 的 历史 切入 ， 主 要 阐述 
RabbitMQ 的 安装 、 使 用 、 配 置 、 管 理 、 运 维 、 原 理 、 扩 展 等 方面 的 细 
节 。 本 书 大 致 可 以 分 为 基础 篇 、 进 阶 篇 和 高 阶 篇 三 个 部 分 。 基 础 篇 首先 
介绍 RabbitMQ 的 基本 安装 及 使 用 方式 ， 方 便 零 基础 的 读者 以 最 舒适 的 
方式 融入 到 RabbitMQ 之 中 。 其 次 介绍 RabbitMQ 的 基本 概念 ， 包 括 生 产 
者 、 消 费 者 、 交 换 器 、 队 列 、 绑 定 等 。 之 后 通过 Java 语 言 讲述 了 客户 端 
如 何 与 RabbitMQ 建 立 〈 关 闭 ) 连接 、 声 明 OHR Zar DSI, BB 
定 关 系 ， 以 及 如 何 发 送 和 消费 消息 等 。 进 阶 篇 讲述 RabbitMQ 的 TTL. 
死 售 、 延 迟 队 列 、 优 先 级 队列 、RPC、 消 息 持 久 化 、 生 产 端 和 消费 端的 
消息 确认 机 制 等 内 容 ， 以 期 读者 能 够 掌握 RabbitMQ 的 使 用 精髓 。 本 书 
中 间 篇 幅 主要 从 RabbitMQ ”的 管理 、 配 置 、 运 维 这 三 个 角度 来 为 读者 提 
供 帮 助 文 档 及 解雇 问题 的 思路 。 高 阶 篇 主要 阐述 RabbitMQ 的 存储 机 
制 、 流 控 及 镜像 队列 的 原理 ， 深 入 地 讲述 RabbitMQ 的 一 些 实现 细节 ， 
便于 读者 加 深 对 RabbitMQ 的 理解 。 本 书 还 涉及 网 络 分 区 的 概念 ， 此 内 
容 可 称 为 魔鬼 篇 ， 需 要 掌握 前 面 的 所 有 内 容 才 可 理解 其 中 的 门道 。 本 书 
最 后 讲述 的 是 RabbitMQ 的 一 些 扩展 内 容 及 附录 ， 供 读者 参考 之 用 。 

本 书 既 可 供 初 学 者 学 习 ， 帮 助 读 者 了 解 RabbitMQ 的 有 具体 细节 及 使 
用 方式 、 原 理 等 ， 也 可 供 相 关 开 发 、 测 试 及 运 维 人 员 人 参考， 给 日 常 工 作 
带 来 启发 。 
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初 识 RabbitMQ 时 ， 我 在 网 上 搜寻 了 大 量 的 相关 资料 以 求 目 己 能 够 
快速 地 理解 它 ， 但 是 这 些 资料 零 零 散 散 而 又 恨 邯 不 齐 。 后 来 叉 寄 布 望 于 
RabbitMQ 的 相关 书籍 ， 或 许 是 它们 都 非 出 目 国人 之 手 ， 里 面 的 陈述 也 
辑 和 案例 描述 都 不 太 符 合 我 目 己 的 思维 习惯 。 最 后 选择 从 头 开 始 目 研 
RabbitMQ， 包 括 阅 读 相 关 源 码 、 翻 阅 官 网 的 资料 以 及 进行 大 量 的 实验 


等 。 





平时 我 也 有 写 博 客 的 习惯 ， 通 音 在 工作 中 遇 到 问题 时 会 结合 所 学 的 
知识 整理 成 文 。 随 着 一 篇 篇 的 积累 ， 也 有 好 几 十 篇 的 内 容 ， 渐 渐 地 也 了 就 
有 了 编撰 成 书 的 想法 。 

本 书 动笔 之 时 我 曾 信心 满 满 ， 以 为 能 够 顺 其 自然 地 完成 这 本 书 ， 但 
征 写 到 四 分 之 一 时 ， 发 现 并 没有 想象 中 的 那么 简单 。 怎 样 才 能 让 理解 领 
悟 汇聚 成 通俗 易 懂 的 文字 表达 ? 怎样 才能 让 书 中 内 容 前 后 贯通 、 由 浅 入 
深 地 转述 ? 有 些 时 候 可 能 知道 怎样 做 、 为 什么 这 么 做 ， 而 没有 反思 其 他 
情形 能 不 能 做 、 怎 样 做 。 为 了 解决 这 些 问 题 ， 我 会 反复 对 书 中 的 内 容 进 
行 迭 代 ， 对 东 些 模糊 的 知识 点 深耕 再 深耕 ， 对 茶 些 案例 场景 进行 反复 的 
测试 ， 不 断 地 完善 。 

在 本 书 编写 之 时 ， 我 常常 回想 当初 作为 小 日 之 时 迫切 地 希望 能 够 了 
解 哪些 内 容 ， 这 些 内 容 又 希望 以 怎样 的 形式 展现 。 所 以 本 书 前 面 几 章 的 
内 容 基 本 上 是 站 在 一 个 小 日 的 视角 来 为 读者 做 一 个 细 肛 的 讲解 ， 相 信 读 
者 在 阅读 完 这 些 内 容 之 后 能 够 具备 合理 使 用 RabbitMQ 的 能 力 。 在 后 面 























的 章节 中 知识 点 会 慢 慢 地 深入 ， 每 阅读 一 章 的 内 容 都 会 对 RabbitMQ 有 
一 个 更 加 深刻 的 认 知 。 


本 书 中 的 所 有 内 容 都 具备 理论 基础 并 全 部 实践 过 ， 书 中 的 内 容 也 是 
我 在 工作 中 的 实践 积累 ， 硕 望 本 书 能 够 让 初学 者 对 RabbitMQ 有 一 个 全 
面 的 认 知 ， 也 希望 有 相关 经 验 的 人 士 可 以 从 本 书 中 得 到 一 些 启 发 ， 汲 取 


一 些 经 验 。 


NAKA 





本 书 共 11 章 ， 前 后 章节 都 有 相关 的 联系 ， 基 本 上 按照 由 浅 入 深 、 由 
表 及 里 的 层次 逐 层 进行 讲解 。 如 果 读 者 对 其 中 的 某 些 内 容 已 经 和 掌握， 可 
以 选择 跳 过 而 翻阅 后 面 的 内 容 ， 不 过 还 是 建议 读者 按照 先后 顺序 进行 阅 
io 

第 1 章 主 要 针对 消息 中 间 件 做 一 个 摘要 性 介绍 ， 包 括 什 么 是 消息 中 
间 件 、 消 息 中 间 件 的 作用 及 特点 等 。 之 后 引入 RabbitMQ， 对 其 历史 和 
相关 特点 做 一 个 简要 概述 。 本 章 最 后 介绍 RabbitMQ 的 安装 及 生产 、 消 
费 的 使 用 示例 。 

第 2 章 主 要 讲述 RabbitMQ 的 入 门 知 识 ， 包 括 生产 者 、 消 费 者 、 队 
列 、 交 换 嚣 、 路 由 键 、 绑 定 、 连 接 及 信道 等 基本 术语 。 本 章 还 阐述 了 
RabbitMQ 与 AMQP 协 议 的 对 应 关系 。 

第 3 章 主 要 介绍 RabbitMQ 客 户 端 开 发 的 简单 使 用 ， 按 照 一 个 生命 周 
期 对 连接 、 创 建 、 生 产 、 消 费 及 关闭 等 几 个 方面 进行 宏观 的 介绍 。 

第 4 章 介 绍 数据 可 靠 性 的 一 些 细 节 ， 并 展示 RabbitMQ 的 几 种 已 具备 
或 衍生 的 高 级 特性 ， 包 括 TIL、 死 信 队 列 、 延 迟 队 列 、 优 先 级 队列 、 
RPC 等 ， 这 些 功 能 在 实际 使 用 中 可 以 让 某 些 应 用 的 实现 变 得 事半功倍 。 

第 5 章 主要 围绕 RabbitMQ 管 理 这 个 主题 展开 ， 包 括 多 租户 、 权 限 、 
用 户 、 应 用 和 集群 管理 、 服 务 端 状 态 等 方面 ， 并 且 从 侧面 讲述 
rabbitmqctl 工 具 和 rabbitmq_management 插 件 的 使 用 。 

第 6 章 主 要 讲述 RabbitMQ 的 配置 ， 以 此 可 以 通过 环境 变量 、 配 置 文 
件 、 运 行 时 参数 (和 策略 ) 等 三 种 方式 来 定制 化 相应 的 服务 。 

第 7 章 主 要 围绕 运 维 层面 展开 论述 ， 主 要 包括 集群 搭建 、 日 志 碍 
看 、 故 障 恢复 、 集 群 迁 移 、 集 群 监控 这 几 个 方面 。 

第 8 章 主 要 讲述 Federation 和 Shovel 这 两 个 插件 的 使 用 、 细 节 及 相关 
原理 。 区 别 于 第 7 章 中 集群 的 部 署 方 式 ，Federation 和 Shovel 可 以 部 署 在 
广域网 中 ， 为 RabbitMQ 提 供 更 广泛 的 应 用 空间 。 

第 9 章 介 绍 RabbitMQ 相 关 的 一 些 原理 ， 主 要 内 容 包 括 RabbitMQ 存 储 
机 制 、 磁 盘 和 内 存 告 警 、 流 挥 机制、 镜像 队列 。 了 解 这 些 实现 的 细节 及 
原理 十 分 必要 ， 它 们 可 以 让 读者 在 过 到 问题 时 能 够 透 过 现象 看 本 质 。 

第 10 章 主要 围绕 网 络 分 区 进行 展开 ， 有 具体 阐述 网 络 分 区 的 意义 ， 如 




















何 查 看 和 处 理 网 络 分 区 ， 以 及 网 络 分 区 所 带 来 的 影响 。 

第 11 章 主要 探讨 RabbitMQ 的 两 个 扩展 内 容 : 消息 退 踪 及 负载 均 
i. HEUER UWA RHE IA RRA Me. Hey HA SIR TIS 
层面 ， 但 是 负载 均衡 一 般 需 要 借助 第 三 方 的 工具 HAProxy、LVS 等 
实现 ， 故 本 书 将 其 视 为 扩展 内 容 。 

读者 讨论 

由 于 笔者 水 平 有 限 ， 书 中 难免 有 错误 之 处 。 在 本 书 出 版 后 的 任何 时 
间 ， 大 你 对 本 书 有 任何 疑问 ， 都 可 以 通过 zhuzhonghua.ideal@qq.com 发 
送 邮 件 给 笔者 ， 也 可 以 到 笔者 的 个 人 博客 http:/blog.csdn.netu013256816 
或 者 个 人 微 信 公众 号 “ 朱 小 煌 的 博客 ”中 留言 ， 回 笔者 阐述 你 的 建议 和 想 
Wx. 
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第 1 章 “RabbitMQ 简 介 








RabbitMQ 是 目前 非常 热门 的 一 款 消息 中 间 件 ， 不 管 是 互联 网 行业 
还 是 传统 行业 都 在 大 量 地 使 用 。RabbitMQ 和 凭借 其 高 可 靠 、 易 扩展 、 高 
可 用 及 丰富 的 功能 特性 受到 越 来 越 多 企业 的 青睐 。 作 为 一 个 合格 的 开发 
者 ， 有 必要 深入 地 了 解 RabbitMQ 的 相关 知识 ， 为 自己 的 职业 生涯 添 砖 
加 瓦 。 








1.1 什么 是 消息 中 间 件 


消息 (Message) 是 指 在 应 用 间 传 送 的 数据 。 消 息 可 以 非常 简单 ， 
比如 只 包含 文本 字符 串 、JSON 等 ， 也 可 以 很 复杂 ， 比 如 内 藤 对 象 。 


消息 队列 中 间 件 〈Message Queue Middleware， 人 简称 为 MQ) 是 指 利 
用 高 效 可 靠 的 消息 传递 机 制 进行 与 平台 无 关 的 数据 交流 ， 并 基于 数据 通 
信 来 进行 分 布 式 系统 的 集成 。 通 过 提供 消息 传递 和 消息 排队 模型 ， 它 可 
以 在 分 布 式 环境 下 扩展 进程 间 的 通信 。 

消息 队列 中 间 件 ， 也 可 以 称 为 消息 队列 或 者 消息 中 间 件 。 筷 一 般 有 
两 种 传递 模式 : 点 对 点 (P2P, Point-to-Point) 模式 和 发 布 /订阅 
(Pub/Sub) 模式 。 点 对 点 模式 是 基于 队列 的 ， 消 息 生 产 者 发 送 消息 到 
队列 ， 消 息 消 费 者 从 队列 中 接收 消息 ， 队 列 的 存在 使 得 消息 的 异步 传输 
成 为 可 能 。 发 布 订 阅 模 式 定 义 了 如 何 问 一 个 内 容 节 点 发 布 和 订阅 消 明 ， 
这 个 内 容 节 点 称 为 主题 (topic) ， 主 题 可 以 认为 是 消息 传递 的 中 介 ， 消 
斩 发 布 者 将 消息 发 布 到 某 个 主题 ， 而 消息 订阅 者 则 从 主题 中 订阅 消息 。 
主题 使 得 消 奶 的 订阅 者 与 消息 的 发 布 者 互相 保持 独立 ， 不 需要 进行 接触 
即 可 保证 消息 的 传递 ， 发 布 /订阅 模式 在 消息 的 一 对 多 广播 时 采用 。 

目前 开源 的 消息 中 间 件 有 很 多 ， 比 较 主流 的 有 RabbitMQ、Kafka、 
ActiveMQ、RocketMQ 等 。 面 癌 消 息 的 中 间 件 《简称 为 MOM， Message 
Oriented Middleware) 提供 了 以 松散 耦合 的 灵活 方式 集成 应 用 程序 的 一 
种 机 制 。 它 们 提供 了 基于 存储 和 转发 的 应 用 程序 之 间 的 异步 数据 发 送 ， 
即 应 用 程序 彼此 不 直接 通信 ， 而 是 与 作为 中 介 的 消息 中 间 件 通信 。 消 息 
中 间 件 提供 了 有 保证 的 消息 发 送 ， 应 用 程序 开发 人 员 无 顷 了 解 远 程 过 程 
调用 CRPC) 和 网 络 通信 协议 的 细节 。 


消息 中 间 件 适用 于 需要 可 靠 的 数据 传送 的 分 布 式 环境 。 采 用 消 妃 中 
间 件 的 系统 中 ， 不 同 的 对 象 之 间 通 过 传递 消息 来 激活 对 方 的 事件 ， 以 完 
成 相应 的 操作 。 发 送 者 将 消息 发 送 给 消息 服务 器 ， 消 妃 服 务 器 将 消 妃 存 
放 在 奋 干 队列 中 ， 在 合适 的 时 候 再 将 消 妃 转发 给 接收 者 。 消 息 中 间 件 能 
在 不 同 平台 之 间 通 信 ， 它 党 被 用 来 屏蔽 各 种 平台 及 协议 之 间 的 特性 ， 实 
现 应 用 程序 之 间 的 协同 ， 其 优点 在 于 能 够 在 客户 和 服务 器 之 间 提 供 同步 












































和 有 异步 的 连接 ， 并 且 在 任何 时 刻 都 可 以 将 消 妃 进行 传送 或 者 存储 转发 ， 
这 也 是 它 比 远程 过 程 调用 更 进步 的 原因 。 


举例 说 明 ， 如 图 1-1 所 示 ， 应 用 程序 A 与 应 用 程序 B 通 过 使 用 消息 中 
间 件 的 应 用 程序 编程 接口 (API，Application Program Interface) 发送 消 
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图 1-1 ”应 用 通过 消息 中 间 件 进行 通信 


消息 中 间 件 将 消息 路 由 给 应 用 程 厅 B， 这 样 消息 就 可 存在 于 完全 不 
同 的 计算 机 上 。 消 息 中 间 件 负责 处 理 网 络 通信 ， 如 果 网 络 连 接 不 可 用 ， 
消息 中 间 件 会 存储 消息 ， 直 到 连接 变 得 可 用 ， 再 将 消息 转 友 给 应 用 程序 
B。 有 灵活 性 的 另 一 方面 体现 在 ， 当 应 用 程序 A 发 送 其 消息 时 ， 应 用 程序 B 
甚至 可 以 处 于 不 运行 状态 ， 消 息 中 间 件 将 保留 这 份 消息 ， 直 到 应 用 程序 
B 开 始 执行 并 消费 消息 ， 这 样 还 防止 了 应 用 程序 A 因为 等 待 应 用 程序 B 消 
费 消 妃 而 出 现 阻塞 。 这 种 异步 通信 方式 要 求 应 用 程序 的 设计 与 现在 大 多 
数 应 用 不 同 。 不 过 对 于 时 间 无 关 或 并 行 处 理 的 场景 ， 它 可 能 是 一 个 极其 
有 用 的 方法 。 























1.2 消 轧 中 间 件 的 作用 


消息 中 间 件 凭借 其 独到 的 特性 ， 在 不 同 的 应 用 场景 下 可 以 展现 不 同 
的 作用 。 忌 的 来 说 ， 消 晨 中 间 件 的 作用 可 以 概括 如 下 。 


fee A: EM H JA ZAR TMM AR Me BT Za is AC ee PL PE 
AN YAEL HATA) Pe Ab GS Be PB aA ee. SEP Be 
层 ， 两 边 的 处 理 过 程 都 要 实现 这 一 接口 ， 这 允许 你 独立 地 扩展 或 修改 两 
边 的 处 理 过 程 ， 只 要 确保 它们 遵守 同样 的 接口 约束 即 可 。 


Tuas FE): 有些 情况 下 ， 处 理 数据 的 过 程 会 失败 。 消 居中 间 
件 可 以 把 数据 进行 持久 化 直到 它们 已 经 被 完全 处 理 ， 通 过 这 一 方式 规避 
了 数据 丢失 风险 。 在 把 一 个 消息 从 消息 中 间 件 中 删除 之 前 ， 需 要 你 的 处 
理 系统 明确 地 指出 该 消息 已 经 被 处 理 完成 ， 从 而 确保 你 的 数据 被 安全 地 
保存 直到 你 使 用 完毕 。 


扩展 性 : ”因为 消息 中 间 件 解 簿 了 应 用 的 处 理 过程 ， 所 以 提高 消 奶 
入 队 和 处 理 的 效率 是 很 容易 的 ， 只 要 另外 增加 处 理 过 程 即 可 ， 不 需要 改 
变 代码 ， 也 不 需要 调 市 参数 。 


HUME: 在 访问 量 剧 增 的 情况 下 ， 应 用 仍然 需要 继续 发 挥 作用 ， 但 
是 这 样 的 突 友 流量 并 不 常见 。 如 果 以 能 处 理 这 类 峰值 为 标准 而 投入 资 
源 ， 无 疑 是 巨大 的 浪费 。 使 用 消息 中 间 件 能 够 使 关键 组 件 支 撑 突 友 访 问 
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可 恢复 性 : “” 当 系统 一 部 分 组 件 失 效 时 ， 不 会 影响 到 整个 系统 。 消 
奶 中 间 件 降低 了 进程 间 的 耦合 度 ， 所 以 即使 一 个 处 理 消 四 的 进程 挂 抒 ， 
加 入 消息 中 间 件 中 的 消 奶 仍然 可 以 在 系统 恢复 后 进行 处 理 。 


顺序 保证 : ”在 大 多 数 使 用 场景 下 ， 数 据 处 理 的 顺序 很 重要 ， 大 部 
分 消息 中 间 件 支持 一 定 程 度 上 的 顺序 性 。 


Bat: 在 任何 重要 的 系统 中 ， 都 会 存在 需要 不 同 处 理 时 间 的 元 
素 。 消 息 中 间 件 通过 一 个 缓冲 层 来 帮助 任务 最 高 效率 地 执行 ， 写 入 消 忆 
中 间 件 的 处 理会 尽 可 能 快速 。 该 缓冲 层 有 助 于 控制 和 优化 数据 流 经 过 系 
统 的 速度 。 












































异步 通信 : ”在 很 多 时 候 应 用 不 想 也 不 需要 立即 处 理 消息 。 消 息 中 
间 件 提供 了 腊 步 处 理 机 制 ， 多 许 应 用 把 一 些 消 妃 放 入 消 恩 中 间 件 中 ， 但 
并 不 立即 处 理 它 ， 在 之 后 需要 的 时 候 再 慢 慢 处 理 。 





1.3 ”RabbitMQ 的 起 源 


RabbitMQ 是 采用 Erlang 语 言 实现 AMQP (Advanced Message 
Queuing Protocol， 高 级 消息 队列 协议 ) MÄE FREF, CRETE 
融 系 统 ， 用 于 在 分 布 式 系统 中 存储 转发 消息 。 


在 此 之 前 ， 有 一 些 消 息 中 间 件 的 商业 实现 ， 比 如 微软 的 
MSMQ (MicroSoft Message Queue) 、IBM 的 WebSphere 等 。 由 于 高 昂 
的 价格 ， 一 般 只 应 用 于 大 型 组 织 机 构 ， 它 们 需要 可 靠 性 、 解 看 及 实时 消 
居 通 信 的 功能 。 由 于 商业 壁 爸 ， 丙 业 MQ 供 应 丙 想 要 解决 应 用 互通 的 问 
题 ， 而 不 是 去 创建 标准 来 实现 不 同 的 MQ 产 品 间 的 互通 ， 或 者 允许 应 用 
程序 更 改 MQ 平 台 。 


为 了 打破 这 个 壁垒 ， 同 时 为 了 能 够 让 消息 在 各 个 消息 队列 平台 间 互 
融 互 通 ，JMS (Java Message Service) 应 运 而 生 。JMS 试 图 通过 提供 公 
共 Java ”API 的 方式 ， 隐 藏 单独 MQ 产品 供应 商 提 供 的 实际 接口 ， 从 而 跨 
越 了 壁垒 ， 以 及 解决 了 互通 问题 。 从 技术 上 讲 ，Java 应 用 程序 只 需 针对 
JMS API 编 程 ， 选 择 合适 的 MQ 驱动 即 可 ，JMS 会 打 理 好 其 他 部 分 。 
ActiveMQ 束 是 JMS 的 一 种 实现 。 不 过 党 试 使 用 单独 标准 化 接口 来 胶合 众 
多 不 同 的 接口 ， 最 终 会 暴露 出 问题 ， 使 得 应 用 程序 变 得 更 加 脆弱 。 所 以 
和 急需 一 种 新 的 消息 通信 标准 化 方案 。 

在 2006 年 6 月 ， 由 Cisco、Redhat、iMatix 等 联合 制定 了 AMQP 的 公开 
标准 ， 由 此 AMQP 登 上 了 历史 的 舞台 。 它 是 应 用 层 协 议 的 一 个 开放 标 
准 ， 以 解决 众多 消息 中 间 件 的 需求 和 拓扑 结构 问题 。 它 为 面向 消息 的 中 
间 件 设计 ， 基 于 此 协议 的 客户 端 与 消息 中 间 件 可 传递 消息 ， 并 不 受 产 
品 、 开 发 语言 等 条 件 的 限制 。 

RabbitMQ 最 初版 本 实现 了 AMQP 的 一 个 关键 特性 : 使 用 协议 本 身 就 
可 以 对 队列 和 交换 堪 (Exchange) 这 样 的 资源 进行 配置 。 对 于 商业 MQ 
供应 商 来 说 ， 资 源 配置 需要 通过 管理 终端 的 特定 工具 才能 完成 。 
RabbitMQ 的 资源 配置 能 力 使 其 成 为 构建 分 布 式 应 用 的 最 完美 的 通信 息 
线 ， 特 别 有 助 于 充分 利用 基于 云 的 资源 和 进行 快速 开发 。 

RabbitMQ 是 由 RabbitMQ Technologies Ltd 开发 并 且 提 供 商 业 支 持 
































Ho WRabbitixt#—-th4, AAS ITE WR H ORAL 
疯狂 ，RabbitMQ 的 开创 者 认为 以 此 命名 这 个 分 布 式 软件 再 合适 不 过 

了 。RabbitMQ Technologies Ltd 在 2010 年 4 月 被 SpringSource (VMWare 
的 一 个 部 门 ) 收购 ， 在 2013 年 5 月 并 入 Pivotal， 其 实 VMWare、Pivotal 和 
EMC 本 质 上 是 一 家 。 不 同 的 是 YMWare 是 独立 上 市 子 公 司 ， 而 Pivotal 是 
整合 了 EMC 的 荣 些 资源 ， 现 在 并 没有 上 市 。 至 今 你 也 可 以 在 RabbitMQ 
的 官网 中 上 的 Logo 劳 看 到 “by Pivotal” 的 字样 ， 如 图 1-2 所 示 。 


中 上 abblt 


图 1-2 ”官网 Logo 


RabbitMQ 发 展 到 今天 ， 被 越 来 越 多 的 人 认可 ， 这 和 它 在 易 用 性 、 
扩展 性 、 可 靠 性 和 高 可 用 性 等 方面 的 单单 表现 是 分 不 开 的 。RabbitMQ 
的 具体 特点 可 以 概括 为 以 下 几 点 。 

信 可靠 性 : RabbitMQ 使 用 一 些 机 制 来 保证 可 靠 性 ， 如 持久 化 、 
传输 确认 及 发 布 确认 等 。 

> ”灵活 的 路 由 : 在 消息 进入 队列 之 前 ， 通 过 交换 器 来 路 由 消息 。 
对 于 典型 的 路 由 功能 ，RabbitMQ 已 经 提供 了 一 些 内 置 的 交换 器 来 实 
现 。 针 对 更 复杂 的 路 由 功能 ， 可 以 将 多 个 交换 器 绑 定 在 一 起 ， 也 可 以 通 
过 插件 机 制 来 实现 自己 的 交换 器 。 

信 扩展 性 : 多 个 RabbitMQ 市 点 可 以 组 成 一 个 集群 ， 也 可 以 根据 
实际 业务 情况 动态 地 扩展 集群 中 节点 。 

> ”高 可 用 性 队列 可 以 在 集群 中 的 机 器 上 设置 镜像 ， 使 得 在 部 分 
节点 出 现 问 题 的 情况 下 队列 仍然 可 用 。 

> ”多 种 协议 :RabbitMQ 除 了 原生 支持 AMQP 协 议 ， 还 文 持 
STOMP、MQTT 等 多 种 消息 中 间 件 协议 。 

+ ”多 语言 客户 端 : RabbitMQ 几 平 支持 所 有 常用 语言 ， 比 如 Java、 
Python、Ruby、PHP、C#、JavaScript 等 。 

> ”管理 界面 ;' RabbitMQ 提 供 了 一 个 易 用 的 用 户 界面 ， 使 得 用 户 
可 以 监控 和 管理 消息 、 集 群 中 的 节点 等 。 











仿 “ 插 件 机 制 :RabbitMQ 提 供 了 许多 插件 ， 以 实现 从 多 方面 进行 
扩展 ， 当 然 也 可 以 编写 目 己 的 插件 。 


1.4 RabbitMQH) 228 X fj He HA 


这 里 首先 介绍 RabbitMQ 的 安装 过 程 ， 然 后 演示 发 送 和 消费 消息 的 
具体 实现 ， 以 期 让 读者 对 RabbitMQ 有 比较 直观 的 感受 。 

前 面 提 到 了 RabbitMQ 是 由 Erlang 语 言 编 写 的 ， 也 正 因 如 此 ， 在 安装 
RabbitMQ 之 前 需要 安装 Erlang。 建 议 采 用 较 新 版 的 Erlang， 这 样 可 以 获 
得 较 多 更 新 和 改进 ， 可 以 到 官网 (http://www.erlang.org/downloads) 下 
载 。 截 止 本 书 撰 稿 ， 最 新 版 本 为 20.0， 本 书 示例 大 多 采用 19.x 的 版 本 。 


本 书 如 无 特 指 ， 所 有 程序 都 是 在 Linux 下 运行 的 ， 毕 竟 RabbitMQ 大 
多 部 署 在 Linux 操 作 系 统 之 中 。 


1.4.1 安装 Erlang 





下 面 首先 演示 Erlang 的 安装 。 第 一 步 ， 解 压 安装 包 ， 并 配置 安 钱 目 
录 ， 这 里 我 们 预备 安装 到 /opt/erlang 目 录 下 : 


[root@hidden ~ ]# tar zxvf otp_src_19.3.tar.gz 
[root@hidden ~ }# cd otp_src_19.3 
[root@hidden otp_src_19.3]# ./configure --prefix=/opt/erlang 


第 二 步 ， 如 果 出 现 类 似 关 键 报错 信息 : No curses library functions 
found。 那 么 此 时 需要 安装 ncurses， 安 装 步 又 〈 遇 到 提示 输入 y 后 直接 回 
车 即 可 ) 如 下 : 


[root@hidden otp_src_19.3]# yum install ncurses-devel 
第 三 步 ， 安 装 Erlang: 

[root@hidden otp_src_19.3]# make 

[root@hidden otp_src_19.3]# make install 


如 果 在 安装 的 过 程 中 出 现 类 似 “No ***** found” 的 提示 ， 可 根据 提 
示 信 息 安 装 相 应 的 包 ， 之 后 再 执行 第 二 或 者 第 三 步 ， 直 到 提示 安装 完毕 





ALE 
第 四 步 ， 修 改 /etc/profile 配 置 文件 ， 添 加 下 面 的 环境 变量 : 
ERLANG HOME=/opt/erlang 
export PATH=$PATH:$ERLANG_HOME/bin 
export ERLANG_HOME 
最 后 执行 如 下 命令 让 配置 文件 生效 : 
[root@hidden otp_src_19.3]# source /etc/profile 


可 以 输入 erl 命 令 来 验证 Erlang 是 否 安 装 成 功 ， 如 果 出 现 类 似 以 下 的 
提示 即 表 示 安 装 成 功 : 


[root@hidden ~ ]# erl 


Erlang/OTP 19 [erts-8.1] [source] [64-bit] [smp:4:4] [async-threads:10] 
[hipe] [kernel-poll:false] 


Eshell V8.1 (abort with ^G) 
1> 





1.4.2 ”RabbitMQ 的 安装 


RabbitMQ 的 安 逆 比 Erlang 的 安装 要 简单 ， 直 接 将 下 载 的 安装 包 解 压 
到 相应 的 目录 下 即 可 ， 官 网 下 载 地 址 : 
http://www.rabbitmq.com/releases/rabbitmq-server/。 本 书 撰 稿 时 的 最 新 版 
本 为 3.6.12， 本 书 示例 大 多 采用 同一 系列 的 3.6.x 版 本 。 

这 里 选择 将 RabbitMQ 安 装 到 与 Erlang 同 一 个 目录 Copt) 下面 : 

[root@hidden ~ ]# tar zvxf rabbitmq-server-generic-unix-3.6.10.tar.gz - 
C /opt 


[root@hidden ~ }# cd /opt 





[root@hidden ~ ]# mv rabbitmq_server-3.6.10 rabbitmq 
同样 修改 /etc/profile 文 件 ， 添 加 下 面 的 环境 变量 : 


export PATH=$PATH:/opt/rabbitmq/sbin 
export RABBITMQ_HOME=/opt/rabbitmq 
之 后 执行 source/etc/profile 命 令 让 配置 文件 生效 。 


1.4.3 ”RabbitMQ 的 运行 


在 修改 了 /etc/profile 配 置 文件 之 后 ， 可 以 任意 打开 一 个 Shell 窗 口 ， 
输入 如 下 命令 以 运行 RabbitMQ 服 务 : 


rabbitmq-server —detached 

在 rabbitmq-server 命 令 后 面 添 加 一 个 “-detached” 参 数 是 为 了 能 够 让 
RabbitMQ 服 务 以 守护 进程 的 方式 在 后 台 运 行 ， 这 样 就 不 会 因为 当前 
Shell 窗口 的 关闭 而 影响 服务 。 

运行 rabbitmqctl ”status 命 令 查 看 RabbitMQ 是 否 正常 启动 ， 示 例如 
下 : 


[root@hidden ~]# rabbitmqctl status 
Status of node rabbit@hidden 
[{pid, 6458}, 
{running applications, 
[{rabbitmq management, "RabbitMQ Management Console","3.6.10"}, 


{rabbitmq_management_agent,"RabbitMQ Management Agent","3.6.10"}, 
{rabbitmq_web dispatch, "RabbitMQ Web Dispatcher","3.6.10"}, 
{rabbit, "RabbitMOQ","3.6.10"}, 
{mnesia,"MNESIA CXC 138 12","4.14.1"}, 
{amqp_client,"RabbitMQ AMQP Client","3.6.10"}, 
{os_mon,"CPO CXC 138 46","2.4.1"}, 
{rabbit common, 
"Modules shared by rabbitmq-server and rabbitmgq-erlang-client", 
"3/6 20"), 
(compiler, ERTS. CXC 138 10","7.0.2"}, 
{inets,"INETS CXC 138 49","6.3.3"}, 
{cowboy,"Small, fast, modular HTTP server.","1.0.4"}, 
{ranch,"Socket acceptor pool for TCP protocols.","1.3.0"}, 
{ssl,"Erlang/OTP SSL application","8.0.2"}, 
{public: key, "Public: key infrastructure","1.2"}, 
{cowlib, "Support library for manipulating Web protocols.","1.0.2"}, 
{GEYHES) "CRYPTON 3).7 ey 
{syntax tools, "Syntax tools","2.1"}, 
{asnl,"The Erlang ASN1 compiler version 4.0.4","4.0.4"}, 
{xmerl,"XML parser","1.3.12"}, 
{sasl, “SASL: CXC 138 11%) "3.0.1" 5, 
{stdlib,"ERTS CXC 138 10","3.1"}, 
(kernel, "ERTS CXC 138 10","5.1"}]}, 
tos, {unix,linux}}, 
{erlang version, 
"Erlang/OTP 19 [erts-8.1] [source] [64-bit] [smp:4:4] 
[async-threads:64] [hipe] [kernel-poll:true]\n"}, 
{memory, 
[{total, 61061688}, 
{connection_readers,0}, 
{connection writers,0}, 
{connection_channels,0}, 
{connection_other, 2832}, 
{queue procs, 2832}, 
{queue slave procs,0}, 
{plugins, 487104}, 
{other proc,21896528}, 
{mnesia, 60800}, 
{metrics, 193616}, 
{mgmt_db, 137720}, 
{msg_index, 43392}, 
{other ets,2485240}, 
{binary, 132984}, 
{code, 24661210}, 
{atom, 1033401}, 
{other system,10114813}]}, 
{alarms,[]}, 
{listéeners, [{(clustering,2Z5672," 33"), {amap, 5672, "22" y {Attp, 15672, "3 2") I Yy 
{vm_memory high watermark,0.4}, 


{vm memory limit, 3301929779}, 
{disk free limit,50000000}, 
{disk free, 30244855808}, 
{file descriptors, 

[{total limit, 924}, {total used,2}, {sockets limit, 829}, {sockets used,0}]}, 
{processes, [{limit, 1048576}, {used, 323}]}, 
{run_queue, 0}, 
{uptime,11}, 
{kernel, {net_ticktime, 60}}] 





如 果 RabbitMQ 正 第 局 动 ， 会 输出 如 上 上 所 示 的 信息 。 当 然 也 可 以 通 
过 rabbitmqctl cluster_status 命 令 来 查看 集群 信息 ， 目 前 只 有 一 个 
RabbitMQ 服 务 节 点 ， 可 以 看 作 单 节点 的 集群 : 


[root@hidden ~ }# rabbitmactl cluster_status 





Cluster status of node rabbit@hidden 

[{nodes,|[ {disc,[rabbit@hidden] }]}, 
{running_nodes,[rabbit@hidden]}, 
{cluster_name,<<"rabbit@hidden">>}, 
{partitions,|[]}, 
{alarms,|{rabbit@hidden,|]}]}] 

在 后 面 的 7.1 市 中 会 对 多 节操 的 集群 配置 进行 介绍 。 





1.4.4 生产 和 消费 消息 





本 节 将 演示 如 何 使 用 RabbitMQ = Java 客户 端 生 产 和 消费 消息 。 本 书 
中 如 无 特殊 说 明 ， 示 例 都 采用 Java 语 言 来 演示 ， 包 括 RabbitMQ 官 方 文档 
基本 上 也 是 采用 Java 语 言 来 进行 演示 的 。 当 然 如 前 面 所 提 及 的 ， 
RabbitMQ7 F ¥ 出 可 以 支持 很 多 种 语言 E o 

目前 最 新 的 RabbitMQ Java 客 户 端 版 本 为 4.2.1， 相 应 的 maven 构 建文 
件 如 下 : 


<!-- https://mvnrepository.com/artifact/com.rabbitmq/amqp-client --> 
<dependency> 
<grouplId>com. rabbitmg</groupId> 
<artifactId>amqp-client</artifactId> 
<version>4.2.1</version> 
</dependency> 





读者 可 以 根据 项 目的 实际 情况 进行 调节 。 

默认 情况 下 ， 访 问 RabbitMQ 服 务 的 用 户 名 和 密码 都 是 “guest*"， 这 
个 账户 有 限制 ， 默 认 只 能 通过 本 地 网 络 〈 如 localhost) 访问 ， 远 程 网 络 
访问 受 限 ， 所 以 在 实现 生产 和 消费 消 晨 之前， 需要 男 外 添加 一 个 用 户 ， 
并 设置 相应 的 访问 权限 。 

添加 新 有 用户， 用 户 名 为 “root”*， 密 码 为 “root123”: 


[root@hidden ~ }# rabbitmqctl add_user root root123 





Creating user "root" ... 

ArootH Fhe ATA ABR 

[root@hidden ~ }# rabbitmaqctl set_permissions -p / root ".*" ".*" ".*" 
Setting permissions for user "root" in vhost "/" ... 

设置 root 用 户 为 管理 员 角 色 : 

[root@hidden ~ ]# rabbitmqctl set_user_tags root administrator 


Setting tags for user "root" to [administrator] ... 


如 果 读者 在 使 用 RabbitMQ 的 过 程 中 遇 到 类 似 如 下 的 报错 ， 那 么 很 
可 能 就 是 账户 管理 的 问题 ， 需 要 根据 上 面 的 步骤 进行 设置 ， 之 后 再 运行 
程序 。 

Exception in thread "main" 
com.rabbitmgq.client.AuthenticationFailureException: ACCESS_REFUSED - 
Login was refused using authentication mechanism PLAIN. For details see 
the broker logfile. 


计算 机 的 世界 是 从 “Hello World! ”开始 的 ， 这 里 我 们 也 治 用 惯例 ， 
首先 生产 者 发 送 一 条 消息 *Hello World! ”至 RabbitMQ 中 ， 之 后 由 消费 者 








消费。 下 面 完 演示 生产 者 客户 并 的 代码 (代码 清单 1-1) ， 接 看 再演 示 
消费 者 客户 端的 代码 (代码 清单 1-2)。 


代码 清单 1-1 生产 者 客户 端 代 码 
package com.zzh.rabbitmq.demo; 


import com.rabbitmg.client.Channel; 

import com.rabbitmgq.client.Connection; 

import com.rabbitmq.client.ConnectionFactory; 
import com.rabbitmq.client.MessageProperties; 
import java.io. IOException; 

import java.util.concurrent.TimeoutException; 


public class RabbitProducer { 
private static final String EXCHANGE NAME = "exchange demo"; 
private static final String ROUTING KEY = "routingkey demo"; 
private static final String QUEUE NAME = "queue demo"; 
private static final String IP_ADDRESS = "192.168.0.2"; 
private static final int PORT = 5672;//RabbitMO 服务 端 默 认 端 口号 为 5672 


public static void main(String[] args) throws IOException, 


TimeoutException, InterruptedException { 


ConnectionFactory factory = new ConnectionFactory(); 


factory.setHost (IP ADDRESS) ; 
factory.setPort (PORT) ; 
factory.setUsername ("root") ; 
factory.setPassword ("root123") ; 


Connection connection = factory.newConnection() ;// 创 建 连接 
Channel channel = connection.createChannel ();// 创 建 信道 


// 创 建 一 个 type="direct"、 持 久 化 的 、 非 自动 删除 的 交换 器 


channel.exchangeDeclare (EXCHANGE NAME, "direct", 


// 创 建 一 个 持久 化 、 非 排他 的 、 非 目 动 删除 的 队列 


true, false, null); 


channel.queueDeclare (QUEUE NAME, true, false, false, null); 


// 将 交换 器 与 队列 通过 路 由 键 绑 定 





channel.queueBind (QUEUE NAME, EXCHANGE NAME, ROUTING KEY); 


// 发 送 一 条 持久 化 的 消息 : hello world! 
String message = "Hello World!"; 


channel .basicPublish(EXCHANGE NAME, ROUTING KEY, 


MessageProperties.PERSISTENT TEXT PLAIN, 
message.getBytes ()); 

// 关 闭 资源 

channel.close(); 

connection.close(); 


为 了 方便 初学 者 能 够 正确 地 运行 本 段 代码 ， 完 成 “新 手 上 路 ”的 任 


务 ， 这 里 将 一 个 完整 的 程序 展示 出 来 。 在 后 面 的 章 
要 ， 都 只 会 展示 出 部 分 关键 代码 。 


节 中 ， 如 无 特别 需 


上 面 的 生产 者 客户 端的 代码 首先 和 RabbitMQ 服 务 器 建立 一 个 连接 
(Connection) ， 然 后 在 这 个 连接 之 上 创建 一 个 信道 (Channel) 。 之 后 
创建 一 个 交换 器 (Exchange) 和 一 个 队列 〈Queue) ， 并 通 

行 绑 定 《在 2.1 节 中 会 有 关于 交换 堪 、 队 列 及 路 由 键 的 详细 解释 ) 。 然 








后 发 关 条 消息 ， 最 后 关闭 资源 。 
代码 清单 1-2 ”消费 者 客户 端 代 码 


package com.zzh.rabbitmq.demo; 


import com.rabbitmgq.client.*; 

import java.io.IOException; 

import java.util.concurrent.TimeUnit; 

import java.util.concurrent.TimeoutException; 


public class RabbitConsumer { 
private static final String QUEUE NAME = "queue demo"; 


private static final String IP ADDRESS = "192.168.0.2"; 
private static final int PORT = 5672; 


public static void main(String[] args) throws IOException, 
TimeoutException, InterruptedException { 
Address[] addresses = new Address [] { 
new Address (IP ADDRESS, PORT) 
}; 
ConnectionFactory factory = new ConnectionFactory(); 
factory.setUsername ("root") ; 
factory.setPassword("root123"); 
// 这 里 的 连接 方式 与 生产 者 的 demo 略 有 不 同 ， 注 意 辨别 区 别 
Connection connection = factory.newConnection (addresses) ;// 创 建 连接 
final Channel channel = connection.createChannel ();// 创 建 信道 
channel.basicQos (64);// 设 置 客 户 端 最 多 接收 未 被 ack 的 消息 的 个 数 
Consumer consumer = new DefaultConsumer (channel) { 
@Override 
public void handleDelivery(String consumerTag, 
Envelope envelope, 
AMQP.BasicProperties properties, 


byte[] body) 
throws IOException { 
System.out.println("recv message: " + new String(body) ); 


bry { 
TimeUnit.SECONDS.sleep (1) ; 

} catch (InterruptedException e) { 
e.printStackTrace() ; 


} 


channel. basicAck (envelope.getDeliveryTag(), false); 


}; 
channel.basicConsume (QUEUE NAME,consumer); 
// 等 待 回 调 函 数 执行 完毕 之 后 ， 关 闭 资 源 
TimeUnit.SECONDS.sleep (5) ; 
channel.close(); 

connection.close(); 


注意 这 里 采用 的 是 继承 DefaultConsumer 的 方式 来 实现 消费 ， 有 过 
RabbitMQ 使 用 经 验 的 读者 也 许 会 喜欢 采用 QueueingConsumer 的 方式 来 
实现 消费 ， 但 是 我 们 并 不 推荐 ， 使 用 QueueingConsumer 会 有 一 些 隐患 。 
同时 ， 在 RabbitMQ ， Java 客户 端 4.0.0 版 本 开始 将 QueueingConsumer 标 记 


为 @Deprecated， 在 后 面 的 大 版 本 中 会 删除 这 个 类 ， 更 多 详细 内 容 可 以 
参考 4.9.3 节 。 

通过 上 面 的 演示 ， 相 信 各 位 读者 对 RabbitMQ 有 了 一 个 初步 的 认 
识 。 但 是 这 也 仅仅 是 个 开始 ， 路 漫漫 其 修 远 今 ， 愿 君 能 上 下 而 求索 。 


15 小 结 


本 章 首 先 针对 消息 中 间 件 做 了 一 个 摘要 性 的 介绍 ， 包 括 什 么 是 消息 
中 间 件 、 消 息 中 间 件 的 作用 及 消息 中 间 件 的 特点 等 。 之 后 引入 
RabbitMQ， 对 其 历史 做 一 个 简单 的 阐述 ， 比 如 RabbitMQ 具 备 哪些 特 
点 。 本 章 后 面 的 篇 幅 介 绍 了 RabbitMQ 的 安装 及 简单 使 用 ， 通 过 演示 生 
产 者 生产 消息 ， 以 及 消费 者 消费 消息 来 给 读者 一 个 对 于 RabbitMQ 的 最 
初 的 印象 ， 为 后 面 的 探索 过 程 打下 基础 。 
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第 1 章 的 内 容 让 我 们 对 消 恩 中 间 件 和 RabbitMQ 本 身 有 了 大 致 的 印 
象 ， 但 这 是 最 浅显 的 。 为 了 能 够 擂 开 RabbitMQ 的 大 门 ， 还 需要 针对 
RabbitMQ 本 身 及 其 所 遵循 的 AMQP 协 议 中 的 一 些 细节 做 进一步 的 探究 。 
在 阅读 本 章 内 容 的 时 候 可 以 带 着 这 样 的 一 些 疑 问 : RabbitMQ 的 模型 架 
构 是 什么 ? AMQP 协 议 又 是 什么 ? 这 两 者 之 间 又 有 何 种 紧密 的 关系 ? 消 
息 从 生产 者 发 出 到 消费 者 消费 这 一 过 程 中 要 经 历 一 些 什么 ? 





2.1 相关 概念 介绍 


RabbitMQ 整 体 上 是 一 个 生产 者 与 消费 者 模型 ， 主 要 负责 接收 、 存 
储 和 转发 消息 。 可 以 把 消息 传递 的 过 程 想象 成 ， 当 你 将 一 个 包 里 送 到 邮 
局 ， 邮局 会 暂 存 并 最 终 将 邮件 通过 邮递 员 送 到 收 件 人 的 手 上 ， 
RabbitMQ 就 好 比 由 邮局 、 邮 箱 和 邮递 员 组 成 的 一 个 系统 。 从 计算 机 术 


语 层面 来 说 ，RabbitMQ 模 型 更 像 是 一 种 交换 机 模型 。 


RabbitMQ 的 整体 模型 架构 如 图 2-1 所 示 。 
Queue? 全 
o% /_\ AD 
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图 2-1 RabbitMQ 的 模型 架构 
2.1.1 Area A Ra 


Producer: 生产 者 ， 就 是 投递 消息 的 一 方 。 


生产 者 创建 消息 ， 然 后 发 布 到 RabbitMQ 中 。 消 息 一 般 可 以 包含 2 个 
部 分 : 消息 体 和 标签 (Label) 。 消 息 体 也 可 以 称 之 为 payload， 在 实际 
应 用 中 ， 消 四 体 一 般 是 一 个 带 有 业务 逻辑 结构 的 数据 ， 比 如 一 个 JSON 
字符 串 。 当 然 可 以 进一步 对 这 个 消息 体 进 行 序列 化 操作 。 消 息 鸭 标签 用 
来 表述 这 条 消息 ， 比 如 一 个 交换 器 的 名 称 和 一 个 路 由 键 。 生 产 者 把 消息 
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交 由 RabbitMQ，RabbitMQ 之 后 会 根据 标签 把 消息 发 送 给 感 兴趣 的 消费 
者 (Consumer) 。 

Consumer: 消费 者 ， 就 是 接收 消息 的 一 方 。 

消费 者 连接 到 RabbitMQ 服 务 器 ， 并 订阅 到 队列 上 。 当 消费 者 消费 
一 条 消息 时 ， 只 是 消费 消息 的 消息 体 (payload) 。 在 消息 路 由 的 过 程 
中 ， 消 息 的 标签 会 丢弃 ， 存 入 到 队列 中 的 消息 只 有 消息 体 ， 消 费 者 也 只 
会 消费 到 消息 体 ， 也 就 不 知道 消息 的 生产 者 是 谁 ， 当 然 消 费 者 也 不 需要 
知道 。 

Broker: 消息 中 间 件 的 服务 节点 。 


对 于 RabbitMQ 来 说 ， 一 个 RabbitMQ Broker 可 以 简单 地 看 作 一 个 
RabbitMQ 服 务 节 点 ， 或 者 RabbitMQ 服 务实 例 。 大 多 数 情况 下 也 可 以 将 
一 个 RabbitMQ Broker 看 作 一 台 RabbitMQ 服 务 器 。 


图 2-2 展 示 了 生产 者 将 消息 存 入 RabbitMQ ”Broker， 以 及 消费 者 从 
Broker 中 消费 数据 的 整个 流程 。 
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CAMQP 协 议 里 这 个 动作 对 应 的 命令 为 Basic.Publish) 到 Broker 中 。 消 费 
者 订阅 并 接收 消息 (AMQP 协 议 里 这 个 动作 对 应 的 命令 为 Basic.Consume 
或 者 Basic.Get) ， 经 过 可 能 的 解 包 处 理 得 到 原始 的 数据 ， 之 后 再 进行 业 
务 处 理 逻 辑 。 这 个 业务 处 理 逻 辑 并 不 一 定 需要 和 接收 消息 的 逻辑 使 用 同 
一 个 线程 。 消 费 者 进程 可 以 使 用 一 个 线程 去 接收 消息 ， 存 入 到 内 存 中 ， 
比如 使 用 Java 中 的 BlockingQueue。 业 务 处 理 逻 辑 使 用 男 一 个 线程 从 内 存 
中 读 取 数据 ， 这 样 可 以 将 应 用 进一步 解 厢 ， 提 高 整个 应 用 的 处 理 效率 。 


2.1.2 ”队列 
Queue: 队列 ， 是 RabbitMQ 的 内 部 对 象 ， 用 于 存储 消息 。 参 考 图 2- 
1， 队 列 可 以 用 图 2-3 表 示 。 
Queue 
图 2-3 ”队列 


RabbitMQ 中 消息 都 只 能 存储 在 队列 中 ， 这 一 点 和 Kafka 这 种 消息 中 
间 件 相反 。Kafka 将 消息 存储 在 topic ($W) 这 个 逻辑 层面 ， 而 相对 应 
的 队列 逻辑 只 是 topic 实 际 存储 文件 中 的 位 移 标 识 。RabbitMQ 的 生产 者 
生产 消息 并 最 终 投递 到 队列 中 ， 消 费 者 可 以 从 队列 中 获取 消息 并 消费 。 

多 个 消费 者 可 以 订阅 同一 个 队列 ， 这 时 队列 中 的 消息 会 被 平均 分 摊 
(Round-Robin， 即 轮 询 ) 给 多 个 消费 者 进行 处 理 ， 而 不 是 每 个 消费 者 
都 收 到 所 有 的 消息 并 处 理 ， 如 图 2-4 所 示 。 
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图 2-4 多 个 消费 者 


RabbitMQ 不 支持 队列 层面 的 广播 消费 ， 如 果 需 要 广播 消费 ， 需 要 
在 其 上 进行 二 次 开发 ， 处 理 罗 辑 会 变 得 异常 复杂 ， 同 时 也 不 建议 这 么 
ti. 


2.1.3 ZHR., KHE, BE 


Exchange: 交换 器 。 在 图 2-4 中 我 们 暂时 可 以 理解 成 生产 者 将 消息 
投递 到 队列 中 ， 实 际 上 这 个 在 RabbitMQ 中 不 会 发 生 。 真 实情 况 是 ， 生 
产 者 将 消息 发 送 到 Exchange (交换 器 ,通常 也 可 以 用 大 写 的 “X” 来 表 
示 ) ， 由 交换 器 将 消息 路 由 到 一 个 或 者 多 个 队列 中 。 如 果 路 由 不 到 ， 或 
许 会 返回 给 生产 者 ， 或 许 直接 丢弃 。 这 里 可 以 将 RabbitMQ 中 的 交换 器 
看 作 一 个 简单 的 实体 ， 更 多 的 细节 会 在 后 面 的 章节 中 有 所 涉及 。 
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图 2-5 “交换 器 

RabbitMQ 中 的 交换 器 有 四 种 类 型 ， 不 同 的 类 型 有 着 不 同 的 路 由 集 
略 ， 这 将 在 下 一 节 的 交换 器 类 型 (Exchange Types) 中 介绍 。 

RoutingKey: 路 由 键 。 生 产 者 将 消息 发 给 交换 器 的 时 候 ， 一 般 会 指 
定 一 个 RoutingKey， 用 来 指定 这 个 消 奶 的 路 由 规则 ， 而 这 个 Routing Key 
需要 与 交换 器 类 型 和 绑 定 键 (BindingKey) 联合 使 用 才能 最 终生 效 。 

在 交换 器 类 型 和 绑 定 键 (BindingKey) 固定 的 情况 下 ， 生 产 者 可 以 
在 发 送 消 息 给 交换 器 时 ， 通 过 指定 RoutingKey 来 决定 消息 流 癌 哪里 。 


Binding: 绑 定 。RabbitMQ 中 通过 绑 定 将 交换 器 与 队列 关联 起 来 ， 
在 绑 定 的 时 候 一 般 会 指定 一 个 绑 定 键 (BindingKey) ， 这 样 RabbitMQ 就 
知道 如 何 正 确 地 将 消息 路 由 到 队列 了 ， 如 图 2-6 所 示 。 
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图 2-6” 绑 定 


生产 者 将 消息 发 送 给 交换 器 时 ， 需 要 一 个 RoutingKey， 当 
BindingKey 和 RoutingKey 相 匹配 时 ， 消 息 会 被 路 由 到 对 应 的 队列 中 。 在 
绑 定 多 个 队列 到 同一 个 交换 器 的 时 候 ， 这 些 绑 定 允 许 使 用 相同 的 
BindingKey。BindingKey 并 不 是 在 所 有 的 情况 下 都 生效 ， 它 依赖 于 交换 
器 类 型 ， 比 如 fanout 类 型 的 交换 器 就 会 无 视 BindingKey， 而 是 将 消 恩 路 
由 到 所 有 绑 定 到 该 交换 器 的 队列 中 。 

对 于 初学 者 来 说 ， 交 换 器 、 路 由 键 、 绑 定 这 几 个 概念 理解 起 来 会 有 
点 睡 深 ， 可 以 对 照 着 代码 清单 1-1 来 加 深 理 解 。 


沿用 本 章 开 头 的 比喻 ， 交 换 器 相当 于 投递 包 训 的 邮箱 ，RoutingKey 
相当 于 填写 在 包 于 上 的 地 址 ，BindingKey 相 当 于 包 右 的 目的 地 ， 当 填写 
在 包 庄 上 的 地 址 和 实际 想 要 投递 的 地 址 相 匹 配 时 ， 那 么 这 个 包 庄 就 会 被 
正确 投递 到 目的 地 ， 最 后 这 个 目的 地 的 “主人 :一 一 队列 可 以 保留 这 个 包 
吉 。 如 果 填 写 的 地 址 出 错 ， 邮 递 员 不 能 正确 投递 到 目的 地 ， 包 囊 可 能 会 
回 退 给 寄 件 人 ， 也 有 可 能 被 丢弃 。 

有 经 验 的 读者 可 能 会 发 现 ， 在 某 些 情形 下 ，RoutingKey 与 
BindingKey 可 以 看 作 同 一 个 东西 。 代 码 清单 2-1 所 展示 的 是 代码 清单 1-1 
中 的 部 分 代码 : 


代码 清单 2-1 RoutingKey 与 BindingKey 











channel.exchangeDeclare (EXCHANGE NAME, "direct", true, false, null); 
channel.queueDeclare (QUEUE NAME, true, false, false, null); 
channel. queueBind (QUEUE NAME, EXCHANGE NAME, ROUTING KEY); 
String message = "Hello World!"; 
channel.basicPublish (EXCHANGE NAME, ROUTING KEY, 
MessageProperties.PERSISTENT TEXT PLAIN, 
message.getBytes ()); 








以 上 代码 声明 了 一 个 direct 类 型 的 交换 器 (交换 器 的 类 型 在 下 一 市 
会 详细 讲述 ) ， 然 后 将 交换 器 和 队列 绑 定 起 来 。 注 意 这 里 使 用 的 字样 
是 “ROUTING_KEY”， 在 本 该 使 用 BindingKey 的 channel.queueBind 方 法 
中 却 和 channel.basicPublish 方 法 同样 使 用 了 RoutingKey， 这 样 做 的 湾 人 台 
词 是 : 这 里 的 RoutingKey 和 BindingKey 是 同一 个 东西 。 在 direct 交 换 器 类 
型 下 ，RoutingKey 和 BindingKey 需 要 完全 匹配 才能 使 用 ， 所 以 上 面 代 码 
中 采用 了 此 种 写法 会 显得 方便 许多 。 

但 是 在 topic 交 换 器 类 型 下 ，RoutingKey 和 BindingKey 之 间 需 要 做 模 
糊 匹 配 ， 两 者 并 不 是 相同 的 。 


BindingKey 其 实 也 属于 路 由 键 中 的 一 种 ， 官 方 解 释 为 : the routing 
key to use for the binding。 可 以 翻译 为 : 在 绑 定 的 时 候 使 用 的 路 由 键 。 
大 多 数 时 候 ， 包 括 官方 文档 和 RabbitMQ Java _ API 中 都 把 BindingKey 和 
RoutingKey 看 作 RoutingKey， 为 了 避免 混 消 ， 可 以 这 么 理解 : 

信 ”在 使 用 绑 定 的 时 候 ， 其 中 需要 的 路 由 键 是 BindingKey。 涉 及 的 
客户 端 方法 如 : channel.exchangeBind、channel.queueBind， 对 应 的 
AMQP 命 令 〔( 详 情 参 见 2.2 节 ) 为 Exchange.Bind、Queue.Bind。 

信 “在 发 送 消息 的 时 候 ， 其 中 需要 的 路 由 键 是 RoutingKey。 涉 及 的 
客户 端 方法 如 channel.basicPublish， 对 应 的 AMQP 命 令 为 Basic.Publish 。 

由 于 某 些 历史 的 原因 ， 包 括 现存 能 搜集 到 的 资料 显示 : 大 多 数 情况 
下 习惯 性 地 将 BindingKey 写 成 RoutingKey， 尤 其 是 在 使 用 direct 类 型 的 交 
换 器 的 时 候 。 本 文 后 面 的 篇 幅 中 也 会 将 两 者 合 称 为 路 由 键 ， 读 者 需要 注 
意 区 分 其 中 的 不 同 ， 可 以 根据 上 面 的 辨别 方法 进行 有 效 的 区 分 。 


2.1.4 than 





RabbitMQ 7 FA 22 kir A fanout, direct. topic. headersix PY 
。AMQP 协 议 里 还 提 到 另外 两 种 类 型 ; System 和 上 自 定 义 ， 这 里 不 予 描 
。 对 于 这 四 种 类 型 下 面 一 一 阐述 。 
fanout 
它 会 把 所 有 发 送 到 该 交换 器 的 消 娠 路 由 到 所 有 与 该 交换 器 绑 定 的 队 
列 中 。 
direct 
direct 类 型 的 交换 器 路 由 规则 也 很 简单 ， 它 会 把 消息 路 由 到 那些 
BindingKey 和 RoutingKey 完 全 匹配 的 队列 中 。 
以 图 2-7 为 例 ， 交 换 器 的 类 型 为 direct， 如 果 我 们 发 送 一 条 消息 ， 并 
在 发 送 消 息 的 时 候 设 置 路 由 键 为 “warning”， 则 消息 会 路 由 到 Queue1 和 
Queue2， 对 应 的 示例 代码 如 下 : 


b= 








channel.basicPublish (EXCHANGE NAME, "warning", 
MessageProperties. PERSISTENT TEXT PLAIN, 
message.getBytes()); 
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图 2-7 ”direct 类 型 的 交换 器 





如 琳 在 友 送 消 姑 的 时 候 设置 路 由 键 为 “info* 或 者 “debug”， 消 恩 只 会 
路 由 到 Queue2。 如 果 以 其 他 的 路 由 键 肥 送 消 恩 ， 则 消息 不 会 路 由 到 这 两 
个 队列 中 。 


topic 


前 面 讲 到 direct 类 型 的 交换 器 路 由 规则 是 完全 匹配 BindingKey 和 











RoutingKey， 但 是 这 种 严格 的 匹配 方式 在 很 多 情况 下 不 能 满足 实际 业务 
的 需求 。topic 类 型 的 交换 器 在 匹配 规则 上 进行 了 扩展 ， 它 与 direct 类 型 
的 交换 器 相似 ， 也 是 将 消息 路 由 到 BindingKey 和 RoutingKey 相 匹配 的 队 
列 中 ， 但 这 里 的 匹配 规则 有 些 不 同 ， 它 约定 : 

依 “RoutingKey 为 一 个 点 号 “.” 分 隅 的 字符 串 〈 被 点 号 “2 分隔 开 的 每 
一 段 独立 的 字符 串 称 为 一 个 单词 ) ， 
如 “com.rabbitmq.client” “java.util.concurrent”、 “com.hidden.client”; 

依 “BindingKey 和 RoutingKey 一 样 也 是 点 号 “.” 分 隔 的 字符 串 ; 


仿 “BindingKey 中 可 以 存在 两 种 特殊 字符 串 “*2 和 “##， 用 于 做 模糊 
匹配 ， 其 中 “*? 用 于 匹配 一 个 单词 ，“ 扩 用 于 匹配 多 规格 单词 〈 可 以 是 零 


is 


以 图 2-8 中 的 配置 为 例 : 
路 由 键 为 “com.rabbitmq.client” 的 消息 会 同时 路 由 到 Queue1 和 





Queue2; 
路 由 键 为 “com.hidden.client” 的 消息 只 会 路 由 到 Queue2 中 ; 
路 由 键 为 “com.hidden.demo” 的 消息 只 会 路 由 到 Queue2 中 ; 
- 路 由 键 为 “java.rabbitmq.demo” 的 消息 只 会 路 由 到 Queuel 中 ; 


路 由 键 为 *java.util.concurrent” 的 消息 将 会 被 丢弃 或 者 返回 给 生产 
者 (需要 设置 mandatory 参 数 ) ， 因 为 它 没 有 匹配 任何 路 由 键 。 
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图 2-8 ”topic 类 型 的 交换 器 
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制定 一 组 键 值 对 ， 当 发 送 消息 到 交换 器 时 ，RabbitMQ 会 获取 到 该 消息 
的 headers (也 是 一 个 键 值 对 的 形式 )， 对 比 其 中 的 键 值 对 是 否 完全 匹配 
队列 和 交换 需 绑 定时 指定 的 键 值 对 ， 如 果 完 全 匹配 则 消息 会 路 由 到 该 队 
列 ， 和 否则 不 会 路 由 到 该 队列 。headers 类 型 的 交换 器 性 能 会 很 差 ， 而 且 也 
不 实用 ， 基 本 上 不 会 看 到 它 的 存在 。 


2.1.5 ”RabbitMQ 运 转 流程 


了 解 了 以 上 的 RabbitMQ 架 构 模 型 及 相关 术语 ， 再 来 回顾 整个 消息 
队列 的 使 用 过 程 。 在 最 初 状态 下 ， 生 产 者 发 送 消息 的 时 候 〈 可 依照 网 2- 
1) : 


(1) 生产 者 连接 到 RabbitMQ Broker， 建 立 一 个 连接 
(Connection) ， 开 局 一 个 信道 (Channel) 〈 详 细 内 容 请 参考 3.1 节 ) 。 


(2) 生产 者 声明 一 个 交换 器 ， 并 设置 相关 属性 ， 比 如 交换 机 类 
型 、 是 否 持久 化 等 〈 详 细 内 容 请 参考 3.2 节 ) 。 


(3) 生产 者 声明 一 个 队列 并 设置 相关 属性 ， 比 如 是 否 排 他 、 是 否 
持久 化 、 是 否 目 动 删除 等 〈 详 细 内 容 请 参考 3.2 节 ) 。 


(4) 生产 者 通过 路 由 键 将 交换 器 和 队列 绑 定 起 来 〈 详 细 内 容 请 参 
考 3.2 节 ) 。 


(5) 生产 者 发 送 消息 至 RabbitMQ _ Broker， 其 中 包含 路 由 键 、 交 换 
器 等 信息 〈 详 细 内 容 请 参考 3.3 节 ) 。 


(6) 相应 的 交换 需 根 据 接收 到 的 路 由 键 碍 找 相 匹 配 的 队列 。 


(7) 如 果 找 到 ， 则 将 从 生产 者 发 送 过 来 的 消息 存 入 相应 的 队列 
中 。 


(8) 如 果 没 有 找到 ， 则 根据 生产 者 配置 的 属性 选择 丢弃 还 是 回 退 
给 生产 者 〈 详 细 内 容 请 参考 4.1 节 ) o 


(9) 关闭 信道 





(10) 关闭 连接 。 

消费 者 接收 消息 的 过 程 : 

(1) 消费 者 连接 到 RabbitMQ Broker， 建 立 一 个 连接 
(Connection) ， 开 局 一 个 信道 (Channel) 。 

(2) 消费 者 向 RabbitMQ _ Broker 请求 消费 相应 队列 中 的 消息 ， 可 能 
会 设置 相应 的 回调 函数 ， 以 及 做 一 些 准 备 工作 (详细 内 容 请 参 参考 3.4 
Teg 

(3) 等 待 RabbitMQ Broker] MFI VBA PAYA, R 
OR JE o 

(4) 消费 者 确认 (ack) 接收 到 的 消息 。 

(5) RabbitMQ 从 队列 中 删除 相应 已 经 被 确认 的 消息 。 

(6) 关闭 信道 。 

(7) 关闭 连接 。 

如 图 2-9 所 示 ， 我 们 又 引入 了 两 个 新 的 概念 : Connection 和 
Channel。 我 们 知道 无 论 是 生产 者 还 是 消费 者 ， 都 需要 和 RabbitMQ 
Broker 建 立 连 接 ， 这 个 连接 就 是 一 条 TCP 连 接 ， 也 就 是 Connection。 一 
有 旦 TCP 连 接 建 立 起 来 ， 客 户 端 紧 接 着 可 以 创建 一 个 AMQP 信 道 

(Channel) ， 每 个 信道 都 会 被 指派 一 个 唯一 的 ID。 信 道 是 建立 在 
Connection 之 上 的 虚拟 连接 ，RabbitMQ 处 理 的 每 条 AMQP 指 令 都 是 通过 
信道 完成 的 。 
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我 们 完全 可 以 直接 使 用 Connection 就 能 完成 信道 的 工作 ， 为 什么 还 





图 2-9 Connection 与 Channel 





要 引入 信道 呢 ? 试 想 这 样 一 个 场景 ， 一 个 应 用 程序 中 有 很 多 个 线程 需要 
从 RabbitMQ 中 消费 消息 ， 或 者 生产 消 筷 ， 那 么 必然 需要 建立 很 多 个 
Connection， 也 就 是 许多 个 TCP 连 接 。 然 而 对 于 操作 系统 而 言 ， 建 立 和 
销毁 TCP 连 接 是 非常 昂贵 的 开销 ， 如 果 遇 到 使 用 高 峰 ， 人 性 能 瓶颈 也 随 之 
显现 。RabbitMQ 采 用 类 似 NIOm (Non-blocking I/O) 的 做 法 ， 选 择 TCP 
连接 复 用 ， 不 仅 可 以 减少 性 能 开销 ， 同 时 也 便于 管理 。 


每 个 线程 把 持 一 个 信道 ， 所 以 信道 复 用 了 Connection 的 TCP 连 接 。 
同时 RabbitMQ 可 以 确保 每 个 线程 的 私密 性 ， 就 像 拥有 独立 的 连接 一 
样 。 当 每 个 信道 的 流量 不 是 很 大 时 ， 复 用 单一 的 Connection 可 以 在 产生 
性 能 瓶颈 的 情况 下 有 效 地 节省 TCP 连 接 资 源 。 但 是 当 信 道 本 身 的 流量 很 
大 时 ， 这 时 候 多 个 信道 复 用 一 个 Connection 就 会 产生 性 能 瓶颈 ， 进 而 使 
整体 的 流量 被 限制 了 。 此 时 束 需 要 开辟 多 个 Connection， 将 这 些 信道 均 
摊 到 这 些 Connection 中 ， 至 于 这 些 相 关 的 调 优 策略 需要 根据 业务 目 身 的 
实际 情况 进行 调节 ， 更 多 内 容 可 以 参考 第 9 章 。 

言 道 在 AMQP 中 是 一 个 很 重要 的 概念 ， 大 多 数 操作 都 是 在 信道 这 个 
层面 展开 的 。 在 代码 清单 1-1 中 也 可 以 看 出 一 些 端 侃 ， 比 如 


























channel.exchangeDeclare. channel.queueDeclare. channel.basicPublish#ll 
channel.basicConsume 等 方法 。RabbitMQ 相 关 的 API 与 AMQP 紧 密 相 连 ， 


比如 channel.basicPublish 对 应 AMQP 的 Basic.Publish 命 令 ， 在 下 面 的 小 节 
中 将 会 为 大 家 一 一 展开 。 


2.2 AMQP 协 议 介绍 


从 前 面 的 内 容 可 以 了 解 到 RabbitMQ 是 遵从 AMQP 协 议 的 ， 换 句 话 
说 ，RabbitMQ 就 是 AMQP 协 议 的 Erlang 的 实现 〈 当 然 RabbitMQ 还 支持 
STOMP?! . MQTT®?! 等 协议 ) 。AMQP 的 模型 架构 和 RabbitMQ 的 模型 
架构 是 一 样 的 ， 生 产 者 将 消息 发 送 给 交换 器 ， 交 换 器 和 队列 绑 定 。 当 生 
产 者 发 送 消息 时 所 携带 的 RoutingKey 与 绑 定时 的 BindingKey 相 匹配 时 ， 
消息 即 被 存 入 相应 的 队列 之 中 。 消 费 者 可 以 订阅 相应 的 队列 来 获取 消 
FA 。 





RabbitMQ 中 的 交换 器 、 交 换 器 类 型 、 队 列 、 绑 定 、 路 由 键 等 都 是 
遵循 的 AMQP 协 议 中 相应 的 概念 。 目 前 RabbitMQ 最 新 版 本 默认 支持 的 是 
AMQP 0-9-1。 本 书 中 如 无 特殊 说 明 ， 都 以 AQMP 0-9-1 为 基准 进行 介 


绍 。 


AMQP 协 议 本 喘 包括 三 层 : 

信 Module Layer: 位 于 协议 最 高 层 ， 主 要 定义 了 一 些 供 客户 端 调 
客户 端 可 以 利用 这 些 命令 实现 自己 的 业务 逻辑 。 例 如 ， 客 户 
端 可 以 使 用 Queue.Declare 命 令 声明 一 个 队列 或 者 使 用 Basic.Consume 订 

阅 消 费 一 个 队列 中 的 消息 。 

+ Session Layers 位 于 中 间 层 ， 主 要 负责 将 客户 端的 命令 发 送 给 
服务 器 ， 再 将 服务 端的 应 答 返 回 给 客户 端 ， 主 要 为 客户 端 与 服务 髓 之 间 
的 通信 提供 可 靠 性 同步 机 制 和 错误 处 理 。 


<% Transport Layer: 位 于 最 底层 ， 主 要 传输 二 进 制 数据 流 ， 提 供 
帧 的 处 理 、 信 道 复 用 、 错 误 检 测 和 数据 表示 等 。 


AMQP 说 到 底 还 是 一 个 通信 协议 ， 通 信 协 议 都 会 涉及 报 文 交互 ， 从 
low-level 层 面 举 例 来 说 ，AMQP 本 身 是 应 用 层 的 协议 ， 其 填充 于 TCP 协 
议 层 的 数据 部 分 。 而 从 high-level 层 面 来 说 ，AMQP 是 通过 协议 命令 进行 
交互 的 。AMQP 协 议 可 以 看 作 一 系列 结构 化 命令 的 集合 ， 这 里 的 命令 代 
表 一 种 操作 ， 类 似 于 HTTP 中 的 方法 (GET, POST, PUT, DELETE 
等 ) 。 








2.2.1 AMQP 生 产 者 流转 过 程 


为 了 形象 地 说 明 AMQP 协 议 命令 的 流转 过 程 ， 这 里 截取 代码 清单 1- 
1 中 的 关键 代码 ， 如 代码 清单 2-2 所 示 。 
代码 清单 2-2 简洁 版 生产 者 代码 


Connection connection = factory.newConnection();// 创 建 连接 

Channel channel = connection.createChannel () ;// 创 建 信道 

String message = "Hello World!"; 

channel.basicPublish (EXCHANGE NAME, ROUTING KEY, 
MessageProperties.PERSISTENT TEXT PLAIN, 
message.getBytes ()); 

// 关 闭 资源 

channel.close(); 

connection.close(); 





当 客 户 端 与 Broker 建 立 连 接 的 时 候 ， 会 调用 factory.newConnection 方 
法 ， 这 个 方法 会 进一步 封装 成 Protocol Header “0-9-1 的 报 文 头发 送 给 
Broker， 以 此 通知 Broker 本 次 交互 采用 的 是 AMQP ”0-9-1 协 议 ， 紧 接着 
Broker 返 回 Connection.Start 来 建立 连接 ， 在 连接 的 过 程 中 涉及 
Connectiion.Start/.Sttart--OK. Connnection.Tunee/.Tune-Ok. Coonnection. 
Oppen/.Open-Ok 这 6 个 命令 的 交互 。 


当 客 户 端 调用 connectionn.createChannnel 方 法 准备 开启 信道 的 时 
候 ， 其 包装 Chhannel.Open 命 令 发 送 给 Broker， 等 待 Channnel.Open-Ok 命 


令 。 








当 客 户 端 发 送 消 息 的 时 候 ， 需 要 调用 channeel.basicPubllish 方 法 ， 对 
应 的 AMQP 命 令 为 Basic.Publlish， 注 意 这 个 命令 和 前 面 涉及 的 命令 略 有 
不 同 ， 这 个 命令 还 包含 了 Content Heeader 和 Content BBody. Content 
HHeader 里 面包 含 的 是 消息 体 的 属性 ， 例 如 ， 投 递 模式 〈 可 以 参考 3.3 
节 ) 、 优 先 级 等 ， 而 ContentBody 包 含 消息 体 本 身 。 

当 客 户 端 发 送 完 消 息 需 要 关闭 资源 时 ， 涉 及 Channnel.Close/.CClose- 
Ok 与 Coonnection.Cloose/.Close-OOk 的 命令 交互 。 详 细 流 转 过 程 如 图 2- 
10 所 示 。 
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图 2-10 ”流转 过 程 


22.2.2 AMQPP 消费 者 流转 过 程 


本 节 我 们 继续 来 看 消费 者 的 流转 过 程 ， 参 考 代码 清单 1-2， 截 取消 
费 端 的 关键 代码 如 代码 清单 2-3 所 示 。 


代码 清单 2-3 简洁 版 消费 者 代码 


Connection cconnection = factory.newConnnection (addressses) ;// 创 


建 连接 


final Channeel channel = connection.creaateChannel () :;/// 创 建 信道 








Consumer connsumer = new DefaultConsumerr (channel) {}/// 


省 略 实现 
channel.basiicQos (64) ; 
channel.basiicConsume (QUEUE_NAME, consumeer ) ; 
等 待 回 调 函 数 执 行 完毕 之 后 ， 关 闭 资 源 
TimeUnit.SECCONDS.sleep (5) ; 
channel.closse () ; 


connection.cclose () ; 


其 详细 流转 过 程 如 图 2-11 所 示 。 
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图 2-11 流转 过 程 
消费 者 客户 端 同样 需要 与 Broker 建 立 连 接 ， 与 生产 者 客户 端 一 样 ， 





协议 交互 同样 涉及 Connection.Start/.Start-Ok、Connection.Tune/.Tune-Ok 
和 Connection. Open/.Open-Ok 等 ， 图 2-11 中 省 略 了 这 些 步 又 ， 可 以 参考 
图 2-10。 


紧 接 着 也 少不了 在 Connection 之 上 建立 Channel， 和 生产 者 客户 端 一 
样 ， 协 议 涉 及 Channel.Open/Open-Ok。 


如 果 在 消费 之 前 调用 了 channel.basicQos (int prefetchCount) 的 方法 
来 设置 消费 者 客户 端 最 大 能 “保持 ”的 未 确认 的 消 恩 数 oe 预 取 个 数 ) ， 
那么 协议 流转 转 会 涉及 Basic.Qos/.Qos-Ok 这 两 个 AMQP 命 令 。 


在 真正 消费 之 前 ， 消 费 者 客户 端 需要 癌 Broker 发 送 Basic.Consume 命 
邻 ( 即 调用 channel.basicConsume 方 法 ) 将 Channel 置 为 接收 模式 ， 之 后 
Broker 回 执 Basic.Consume-Ok 以 告诉 消费 者 客户 端 准备 好 消费 消息 。 紧 
接着 Broker 向 消费 者 客户 端 推送 (Push) 消息 ， 即 Basic.Deliver 命 令 ， 有 
意思 的 是 这 个 和 Basic.Publish 命 令 一 样 会 携带 Content Header Content 
Body。 


消 AA REN 消息 并 正确 消费 之 后 ， 辐 Broker 发 送 确认 ， 即 
Basic.Ack 命 令 。 

在 消费 者 停止 消费 的 时 候 ， 主 动 关 闭 连 接 ， 这 点 和 生产 者 一 样 ， 涉 
及 Channel.Close/.Close-Ok 和 Connection.Close/.Close-Ok。 








2.2.33 ”AMQP 命 令 概 哆 


AMQP ”0-9-1 协议 中 的 命令 远 远 不 止 上 面 所 涉及 的 这 些 ， 为 了 让 读 
者 在 过 到 其 他 命令 的 时 候 能 够 迅 速 合 赔 相关 信息 思 ， 下 面 列举 了 AMQP 0- 
9-1 协 议 主要 的 命令 ， 包 含 名 称 、 是 全 包含 内 容 体 (Content Body) 、 对 
应 客户 端 中 相应 的 方法 及 简要 描述 等 四 个 维度 进行 次 明 ， 有 具体 如 表 2-1 
所 示 。 


表 2-1 AMQP 命 令 


是 否 包含 内 容 体 对 应 客户 端 中 的 方法 
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对 应 客户 端 中 的 方法 
同上 
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23 小结 


本 章 主 要 讲述 的 是 RabbitMQ 的 入 门 知 识 ， 首 先 介绍 了 生产 者 
(Producer) 、 消 费 者 (Consumer) 、 队 列 〈Queue) 、 交 换 器 
(Exchange) 、 路 由 键 (RoutingKey) 、 绑 定 (Binding) 、 连 接 
(Connection) 和 信道 (Channel) 等 基本 术语 ， 还 介绍 了 交换 器 的 类 
#4: fanout、direct、topic ”和 headers。 之 后 通过 介绍 RabbitMQ 的 运转 流 
程 来 加 深 对 基本 术语 的 理解 。 

RabbitMQ 可 以 看 作 AMQP 协 议 的 具体 实现 ，2.2 节 还 大 致 介绍 了 
AMQP 命 令 以 及 与 RabbitMQ 客 户 端 中 方法 如 何 一 一 对 应 ， 包 括 对 各 个 整 
个 生产 消费 消息 的 AMQP 命 令 的 流程 介绍 。 最 后 展示 了 AMQP 0-9-1 中 党 
用 的 命令 与 RabbitMQ 客 户 端 中 方法 的 映射 关系 。 














[LNIO， 也 称 非 阻塞 TO， 包 含 三 大 核心 部 分 : Channel (信道 ) . Buffer (IX) 和 
Selector (选择 器 ) 。NIO 基 于 Channel 和 Buffer 进 行 操 作 ， 数 据 总 是 从 信道 读 取 数据 到 缓冲 区 

中 ， 或 者 从 缓冲 区 写 入 到 信道 中 。Selector 用 于 监听 多 个 信道 的 事件 〈 比 如 连接 打开 ， 数 据 到 达 
等 ) 。 因 此 ， 单 线程 可 以 监听 多 个 数据 的 信道 。NIO 中 有 一 个 很 有 名 的 Reactor 模 式 ， 有 兴趣 的 
读者 可 以 深入 研究 。 


[2] STOMP， 即 Simple (or Streaming) Text Oriented Messaging Protocol, fÆ GM) 文本 面向 
消息 协议 ， 它 提供 了 一 个 可 互 操作 的 连接 格式 ， 运 行 STOMP 客 户 端 与 任意 STOMP 消 息 代 理 
(Broker) 进行 交互 。STOMP 协 议 由 于 设计 简单 ， 易 于 开发 客户 端 ， 因 此 在 多 种 语言 和 平台 上 
得 到 广泛 的 应 用 。 


[3] MQTT， 即 Message Queuing Telemetry Transport， 消 息 队 列 遥 测 传输 ， 是 IBM 开 发 的 一 个 即 
时 通信 协议 ， 有 可 能 成 为 物 联 网 的 重要 组 成 部 分 。 该 协议 文 持 所 有 平台 ， 几 乎 可 以 把 所 有 物 联 
网 和 外 部 连接 起 来 ， 被 用 来 当 作 传 感 器 和 制动器 的 通信 协议 。 











































































































Rot AP mI ACTA 


RabbitMQ Java 客户 端 使 用 com.rabbitmq.client 作 为 顶级 包 名 ， 关 键 
的 Class 和 JInterface 有 Channel、Connection、ConnectionFactory、 
Consumer 等 。AMQP 协 议 层面 的 操作 通过 Channel 接 口 实现 。Connection 
是 用 来 开启 Channel〈 信 道 ) 的， 可 以 注册 事件 处 理 器 ， 也 可 以 在 应 用 
结束 时 关闭 连接 。 与 RabbitrMQ 相 关 的 开发 工作 ， 基 本 上 也 是 围绕 
Connection 和 Channel 这 两 个 类 展开 的 。 本 章 按 照 一 个 完整 的 运转 流程 进 
行 讲 解 ， 详 细 内 容 有 这 几 点 : 连接 、 交 换 器 /队列 的 创建 与 绑 定 、 发 送 
消息 、 消 费 消息 、 消 费 消 息 的 确认 和 关闭 连接 。 





3.1 连接 RabbitMQ 


下 面 的 代码 《代码 清单 3-1) 用 来 在 给 定 的 参数 〈IP 地 址 、 端 口 
号 、 用 户 名 、 密 码 等 ) 下 连接 RabbitMQ: 


代码 清单 3-1 

ConnectionFactory factory = new ConnectionFactory (©) ; 
factory.setUsername (USERNAME) ; 

factory.setPassword (PASSWORD) ; 

factory.setVirtualHost (virtualHost) ; 

factory.setHost (IP_ADDRESS) ; 

factory.setPort (PORT) ; 

Connection conn = factory.newConnection () ; 

也 可 以 选择 使 用 URI 的 方式 来 实现 ， 示 例如 代码 清单 3-2 所 示 。 
代码 清单 3-2 

ConnectionFactory factory = new ConnectionFactory (©) ; 
factory.setUri C"amap://userName:password@ipAddress:portNumber/vi 
Connection conn = factory.newConnection () ; 

Connection 接 口 被 用 来 创建 一 个 Channel; 

Channel channel = conn.createChannel () ; 

在 创建 之 后 ，Channel 可 以 用 来 发 送 或 者 接收 消 轧 了 。 

注意 要 点 : 


Connection 可 以 用 来 创建 多 个 Channel 实 例 ， 但 是 Channel 实 例 不 能 
在 线程 则 共享 ， 应 用 程序 应 该 为 每 一 个 线程 开辟 一 个 Channel。 某 些 情 
况 下 Channel 的 操作 可 以 并 发 运行 ， 但 是 在 其 他 情况 下 会 导致 在 网 络 上 
出 现 错误 的 通信 帧 交错 ， 同 时 也 会 影响 发 送 方 确认 (publisher confirm) 








机 制 的 运行 《详细 可 以 参考 4.8 节 ) ， 所 以 多 线程 间 共 有 部 Channel 实 例 是 
非 线程 安全 的 。 


Channel 或 者 Connection 中 有 个 isOpen 方 法 可 以 用 来 检测 其 是 否 已 处 
于 开局 状态 〈 关 于 Channel 或 者 Connection 的 状态 可 以 参考 3.6 节 ) 。 但 并 
不 推荐 在 生产 环境 的 代码 上 使 用 isOpen 方 法 ， 这 个 方法 的 返回 值 依赖 于 
shutdownCause 〈 人 参考 下 面 的 代码 ) 的 存在 ， 有 可 能 会 产生 竞争 ， 代 码 
清单 3-3 是 isOpen 方 法 的 源码 : 


代码 清单 3-3 isOpen 方 法 的 源码 


public boolean isOpen() { 
synchronized(this.monitor) { 
return this.shutdownCause == null; 
} 
} 


错误 地 使 用 isOpen 方 法 示例 代码 如 代码 清单 3-4 所 示 。 
代码 清单 3-4 错误 地 使 用 isOpen 方 法 


public void brokenMethod(Channel channel) 
{ 
if (channel.isOpen()) 
{ 
// The following code depends on the channel being in open state. 
// However there is a possibility of the change in the channel state 
// between isOpen() and basicQos(1) call 


channel .basicQos (1); 


} 


通常 情况 下 ， 在 调用 createXXX 或 者 hewXXX 方 法 之 后 ， 我 们 可 以 
简单 地 认为 Connection 或 者 Channel 已 经 成 功 地 处 于 开启 状态 ， 而 并 不 会 
在 代码 中 使 用 isOpen 这 个 检测 方法 。 如 果 在 使 用 Channel 的 时 候 其 已 经 处 
于 关闭 状态 ， 那 么 程序 会 抛 出 一 个 
com.rabbitmq.client.ShutdownSignalException， 我 们 只 需 捕 获 这 个 异常 即 
可 。 当 然 同 时 也 要 试 着 捕获 IOException 或 者 SocketException， 以 防 
Connection 意 外 关闭 。 示 例 代 码 如 代码 清单 3-5 所 示 。 


代码 清单 3-5 


public void validMethod(Channel channel) 


{ 
try { 


channel .basicQos (1); 
} catch (ShutdownSignalException sse) { 
// possibly check if channel was closed 
// by the time we started action and reasons for 
// closing it 


} catch (IOException ioe) { 
// check why connection was closed 


3.2 (EH AC HR aS FAI 


交换 器 和 队列 是 AMQP 中 high-level 层 面 的 构建 模块 ， 应 用 程序 需 确 
它们 的 时 候 就 已 经 存在 了 ， 在 使 用 之 前 需要 先 声 明 (declare) 

代码 清单 3-6 演 示 了 如 何 声 明 一 个 交换 如 和 队列 : 

代码 清单 3-6 

channel.exchangeDeclare (exchangeName, "direct", true) ; 

String queueName = channel.queueDeclare () .getQueue () ; 


channel.queueBind (queueName, exchangeName, routingKey) ; 


上 面 创 建 了 一 个 持久 化 的 、 非 目 动 删除 的 、 绑 定 类 型 为 direct 的 区 
换 右 ， 同 时 也 创建 了 一 个 非 持 久 化 的 、 排 他 的 、 目 动 删除 的 队列 “此 队 
列 的 名 称 由 RabbitMQ 上 自动 生成 ) 。 这 里 的 交换 器 和 队列 也 都 没有 设置 
特殊 的 参数 。 


上 面 的 代码 也 展示 了 如 何 使 用 路 由 键 将 队列 和 交换 器 绑 定 起 来 。 上 
面 声 明 的 队列 具备 如 下 特性 : 只 对 当前 应 用 中 同一 个 Connection 层 面 可 
用 ， 同 一 个 Connection 的 不 同 Channel 可 共用 ， 并 且 也 会 在 应 用 连接 断 开 
时 自动 删除 。 


如 果 要 在 应 用 中 共 至 一 个 队列 ， 可 以 做 如 下 声明 ， 如 代码 清单 3-7 
所 示 。 


代码 清单 3-7 
channel.exchangeDeclare (exchangeName, "direct", true) ; 
channel.queueDeclare (queueName, true, false, false, null) ; 


channel.queueBind (queueName, exchangeName, routingKey ) ; 


这 里 的 队列 被 声明 为 持久 化 的 、 非 排他 的 、 非 目 动 删除 的 ， 而 且 也 
被 分 配 马 一 个 确定 的 已 知 的 名 称 《〈 由 客户 端 分 配 而 非 RabbitMQ 目 动 生 
成 ) 。 


注意 : Channel 的 API 方 法 都 是 可 以 重 载 的 ， 比 如 exchangeDeclare、 
queueDeclare。 根 据 参 数 不 同 ， 可 以 有 不 同 的 重 载 形式 ， 根 据 自身 的 需 
要 进行 调用 。 

生产 者 和 消费 者 都 可 以 声明 一 个 交换 器 或 者 队列 。 如 有 果 尝 试 声明 一 
个 已 经 存在 的 交换 器 或 者 队列 ， 只 要 声明 的 参数 完全 匹配 现存 的 交换 器 
或 者 队列 ，RabbitMQ 就 可 以 什么 都 不 做 ， 并 成 功 返 回 。 如 果 声 明 的 参 
数 不 匹 配 则 会 抛 出 异常 。 














3.2.1 exchangeDeclare 方 法 详解 





exchangeDeclare 有 多 个 重 载 方法 ， 这 些 重 载 方法 都 是 由 下 面 这 个 方 
法 中 缺 省 的 某 些 参数 构成 的 。 


Exchange.DeclareOk exchangeDeclare (String exchange, 
String type, boolean durable, 
boolean autoDelete, boolean internal, 
Map<String, Object> arguments) throws IOException; 


这 个 方法 的 返回 值 是 Exchange.DeclareOK， 用 来 标识 成 功 声 明了 一 
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各 个 参数 详细 说 明 如 下 所 述 。 

信 exchange: 交换 器 的 名 称 。 

+> type: 交换 器 的 类 型 ， 常 见 的 如 fanout、direct、topic， 详 情 参 
见 2.1.4 闻 。 

+% durable: 设置 是 否 持久 化 。durable 设 置 为 true 表 示 持 久 化 ， 反 
之 是 非 持 久 化 。 持 久 化 可 以 将 交换 器 存盘 ， 在 服务 器 重启 的 时 候 不 会 丢 
失 相 关 信 息 。 


<% autoDelete: 设置 是 否 自动 删除 。autoDelete 设 置 为 true 则 表示 
目 动 删 除 。 自 动 删除 的 前 提 是 至 少 有 一 个 队列 或 者 交换 器 与 这 个 交换 器 
绑 定 ， 之 后 所 有 与 这 个 交换 器 绑 定 的 队列 或 者 交换 占 都 与 此 解 绑 。 注 意 
不 能 错误 地 把 这 个 参数 理解 为 :“ 当 与 此 交换 器 连接 的 客户 端 都 断 开 
时 ，RabbitMQ 会 自动 删除 本 交换 器 ”。 





+ interna: 设置 是 否 是 内 置 的 。 如 果 设 置 为 tue， 则 表示 是 内 置 
的 交换 堪 ， 客 户 端 程序 无 法 直接 发 送 消 息 到 这 个 交换 器 中 ， 只 能 通过 区 
换 器 路 由 到 交换 器 这 种 方式 。 

+ argument: 其 他 一 些 结构 化 参数 ， 比 如 alternate-exchange CA 
天 alternateexchange 的 详情 可 以 参考 4.1.3 市 )。 

exchangeDeclare 的 其 他 重 载 方法 如 下 : 


(1) Exchange.DeclareOk exchangeDeclare (String exchange, String 
type) throws IOException; 














(2) Exchange.DeclareOk exchangeDeclare (String exchange, String 
type, boolean durable) throws IOException; 


(3) Exchange.DeclareOk exchangeDeclare (String exchange, String 
type, boolean durable, boolean autoDelete, Map<String, Object> 
arguments) throws IOException; 


与 此 对 应 的 ， 将 第 二 个 参数 String type 换 成 BuiltInExchangeType 
type 对 应 的 几 个 重 载 方法 (不 常用 ) : 
(1) Exchange.DeclareOk exchangeDeclare (String exchange, 
BuiltinExchangeType type) throws IOException; 


(2) Exchange.DeclareOk exchangeDeclare (String exchange, 
BuiltinExchangeType type, boolean durable) throws IOException; 


(3) Exchange.DeclareOk exchangeDeclare (String exchange, 
BuiltinExchangeType type, boolean durable, boolean  autoDelete, 
Map<String, Object> arguments) throws IOException; 


(4) Exchange.DeclareOk exchangeDeclare (String exchange, 
BuiltinExchangeType type, boolean durable, boolean autoDelete, boolean 
internal, Map<String, Object> arguments) throws IOException; 


与 exchangeDeclare 师 出 同门 的 还 有 几 个 方法 ， 比 如 
exchangeDeclareNoWait 方 法 ， 具 体 定 义 如 下 (当然 也 有 
BuiltExchangeType 版 的 ， 这 里 就 不 展开 了 ) : 





void exchangeDeclareNoWait (String exchange, 
String type, 
boolean durable, 
boolean autoDelete, 
boolean internal, 
Map<String, Object> arguments) throws IOException; 


这 个 exchangeDeclareNoWait 比 exchangeDeclare 多 设置 了 一 个 nowait 
参数 ， 这 个 nowait 参 数 指 的 是 AMQP 中 Exchange.Declare 命 令 的 参数 ， 意 
思 是 不 需要 服务 器 返回 ， 注 意 这 个 方法 的 返回 值 是 void， 而 普通 的 
exchangeDeclare 方 法 的 返回 值 是 Exchange.DeclareOk， 意 思 是 在 客户 端 
声明 了 一 个 交换 器 之 后 ， 需 要 等 待 服务 器 的 返回 (服务 器 会 返回 
Exchange.Declare-Ok 这 个 AMQP 命 令 ) 。 


针对 “exchangeDeclareNoWait 不 需要 服务 占 任 何 返 回 值 ” 这 一 点 ， 考 
虑 这 样 一 种 情况 ， 在 声明 完 一 个 交换 费 之 后 (实际 服务 器 还 并 未 完成 交 
换 絮 的 创建 )， 那 么 此 时 客户 病 紧 接着 使 用 这 个 交换 占 ， 必 然 会 及 生 弄 
常 。 如 果 没 有 特殊 的 缘由 和 应 用 场景 ， 并 不 建议 使 用 这 个 方法 。 

这 里 还 有 师 出 同门 的 男 一 个 方法 exchangeDeclarePassive， 这 个 方法 
的 定义 如 下 : 

Exchange.DeclareOk exchangeDeclarePassive (String name) throws 
IOException; 

这 个 方法 在 实际 应 用 过 程 中 还 是 非常 有 用 的 ， 它 主要 用 来 检测 相应 
的 交换 器 是 否 存 在 。 如 果 存 在 则 正常 运 回 ; 如 果 不 存 在 则 抛 出 异常 : 
404 channel exception， 同 时 Channel 也 会 被 关闭 。 

有 声明 创建 交换 器 的 方法 ， 当 然 也 有 删除 交换 才 的 方法 。 相 应 的 方 
法 如 下 : 


(1) Exchange.DeleteOk exchangeDelete (String exchange) throws 
IOException; 














(2) void exchangeDeleteNoWait (String exchange, boolean 
ifUnused) throws IOException; 


(3) Exchange.DeleteOk exchangeDelete (String exchange, boolean 
ifUnused) throws IOException; 


其 中 exchange 表 示 交 换 器 的 名 称 ， 而 ifUnused 用 来 设置 是 否 在 交换 
器 没有 被 使 用 的 情况 下 删除 。 如 果 isUnused 设 置 为 tue， 则 只 有 在 此 交 
换 器 没有 被 使 用 的 情况 下 才 会 被 删除 ， 如 果 设 置 false， 则 无 论 如 何 这 个 
交换 器 都 要 被 删除 。 


3.2.2 queueDeclare 方 法 详解 
queueDeclare 相 对 于 exchangeDeclare 方 法 而 言 ， 重 载 方法 的 个 数 就 


少 很 多 ， 它 只 有 两 个 重 载 方法 : 
(1) Queue.DeclareOk queueDeclare () throws IOException; 





(2) Queue.DeclareOk queueDeclare (String queue, boolean durable, 
boolean exclusive, boolean autoDelete, Map<String, Object> arguments ) 
throws IOException; 


不 带 任 何 参数 的 queueDeclare 方 法 默认 创建 一 个 由 RabbitMQ 命 名 的 
(类 似 这 种 amq.gen-LhQzlgv3GhDOv8PIDabOXA 和 名称， 这 种 队列 也 称 
之 为 匿名 队列 ) 、 排 他 的 、 目 动 删 除 的 、 非 持久 化 的 队列 。 


方法 的 参数 详细 说 明 如 下 所 述 。 
+ queue: 队列 的 名 称 。 


+ durable: 设置 是 否 持久 化 。 为 true 则 设置 队列 为 持久 化 。 持 入 
化 的 队列 会 存盘 ， 在 服务 器 重启 的 时 候 可 以 保证 不 丢失 相关 信息 。 


+ exclusive: 设置 是 人 否 排他 。 为 true 则 设置 队列 为 排他 的 。 如 果 
一 个 队列 被 声明 为 排他 队列 ， 该 队列 仅 对 首次 声明 它 的 连接 可 见 ， 并 在 
连接 断 开 时 目 动 删除 。 这 里 需要 注意 三 点 : 排他 队列 是 基于 连接 
(Connection) 可见 的 ， 同 一 个 连接 的 不 同 信 道 (Channel) 是 可 以 同时 
访问 同一 连接 创建 的 排他 队列 ; “首次 ?是 指 如 果 一 个 连接 已 经 声明 了 一 
个 排他 队列 ， 其 他 连接 是 不 允许 建立 同名 的 排他 队列 的 ， 这 个 与 普通 队 
NAS Tel; 即使 该 队列 是 持久 化 的 ， 一 旦 连接 关闭 或 者 客户 端 退 出 ， 该 排 
他 队列 都 会 被 自动 删除 ， 这 种 队列 适用 于 一 个 客户 端 同时 发 送 和 读 取 消 
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< autoDelete: 设置 是 否 目 动 删除 。 为 true 则 设置 队列 为 目 动 删 











除 。 上 自动 删除 的 前 提 是 ， 至 少 有 一 个 消费 者 连接 到 这 个 队列 ， 之 后 所 有 
与 这 个 队列 连接 的 消费 者 都 断 开 时 ， 才 会 自动 删除 。 不 能 把 这 个 参数 错 
误 地 理解 为 :“ 当 连接 到 此 队列 的 所 有 客 己 端 断 开 时 ， 这 个 队列 自动 删 
除 ”， 因 为 生产 者 客户 端 创建 这 个 队列 ， 或 者 没有 消费 者 客户 端 与 这 个 
队列 连接 时 ， 都 不 会 自动 删除 这 个 队列 。 
+ arguments: 设置 队列 的 其 他 一 些 参数 ， 如 x-message-ttl、x- 

expires. x-max-length, x-max-length-bytes. x-dead-letter-exchange, x- 
deadletter-routing-key. x-max-priority<$ 。 








注意 要 点 : 

生产 者 和 消费 者 都 能 够 使 用 queueDeclare 来 声明 一 个 队列 ， 但 是 如 
果 消 费 者 在 同一 个 信道 上 订阅 了 男 一 个 队列 ， 就 无 法 再 声明 队列 了 。 必 
须 先 取消 订阅 ， 然 后 将 信道 置 为 “传输 ”模式 ， 之 后 才能 声明 队列 。 

对 应 于 exchangeDeclareNoWait 方 法 ， 这 里 也 有 一 个 
queueDeclareNoWait 方 法 : 








void queueDeclareNoWait (String queue, boolean durable, boolean 
exclusive, boolean autoDelete, Map<String, Object> arguments) throws 
IOException; 


方法 的 返回 值 也 是 void， 表 示 不 需要 服务 端的 任何 返回 。 同 样 也 需 
要 注意 ， 在 调用 完 queueDeclareNoWait 方 法 之 后 ， 紧 接着 使 用 声明 的 队 
列 时 有 可 能 会 发 生 和 异常 情况 。 

同样 这 里 还 有 一 个 queueDeclarePassive 的 方法 ， 也 比较 常用 。 这 个 
方法 用 来 检测 相应 的 队列 是 否 存在 。 如 果 存 在 则 正常 返回 ， 如 果 不 存 在 
则 抛 出 异常 404 channel exception， 同 时 Channel 也 会 被 关闭 。 方 法 定 
义 如 下 : 

Queue.DeclareOk queueDeclarePassive (String queue) throws 
IOException; 


与 交换 器 对 应 ， 关 于 队列 也 有 删除 的 相应 方法 : 


(1) Queue.DeleteOk queueDelete (String queue) throws 
IOException; 


(2) Queue.DeleteOk queueDelete (String queue, boolean ifUnused, 


boolean ifEmpty) throws IOException; 


(3) void queueDeleteNoWait (String queue, boolean ifUnused, 
boolean ifEmpty) throws IOException; 


其 中 queue 表 示 队 列 的 名 称 ，ifUnused 可 以 参考 上 一 小 节 的 交换 器 。 
ifEmpty 设 置 为 true 表 示 在 队列 为 空 〈 队 列 里面 没 有 任何 消息 堆积 ) 的 情 
况 下 才能 够 删除 。 

与 队列 相关 的 还 有 一 个 有 意思 的 方法 queuePurge， 区 别 于 
queueDelete， 这 个 方法 用 来 清空 队列 中 的 内 容 ， 而 不 删除 队列 本 号 ， 具 
体 定义 如 下 : 


Queue.PurgeOk queuePurge (String queue) throws IOException; 











3.2.3 queueBind 方 法 详解 
将 队列 和 交换 器 绑 定 的 方法 如 下 ， 可 以 与 前 两 节 中 的 方法 定义 进行 
Zeus 


(1) Queue.BindOk queueBind (String queue, String exchange, 
String routingKey) throws IOException; 


(2) Queue.BindOk queueBind (String queue, String exchange, 
String routingKey, Map<String, Object> arguments) throws IOException; 


(3) void queueBindNoWait (String queue, String exchange, String 
routingKey, Map<String, Object> arguments) throws IOException; 


方法 中 涉及 的 参数 详解 。 

< queue: 队列 名 称 ; 

<% exchange: 交换 器 的 名 称 ; 

仿 routingKey: 用 来 绑 定 队列 和 交换 器 的 路 由 刍 ; 
v argument: 定义 绑 定 的 一 些 参数 。 


不 仅 可 以 将 队列 和 交换 顺 绑 定 起 来 ， 也 可 以 将 已 经 被 绑 定 的 队列 和 
交换 器 进行 解 绑 。 具 体 方法 可 以 参考 如 下 (具体 的 参数 解释 可 以 参考 前 


面 的 内 容 ， 这 里 不 再 歼 述 〉: 
(1) Queue.UnbindOk queueUnbind (String queue, String exchange, 
String routingKey ) throws IOException; 


(2) Queue.UnbindOk queueUnbind (String queue, String exchange, 
String routingKey, Map<String, Object> arguments) throws IOException; 


3.2.4 ”exchangeBind 方 法 详解 


我 们 不 仅 可 以 将 交换 器 与 队列 绑 定 ， 也 可 以 将 交换 器 与 交换 器 绑 
定 ， 后 者 和 前 者 的 用 法 如 出 一 略 ， 相 应 的 方法 如 下 : 
(1) Exchange.BindOk exchangeBind (String destination, String 
source, String routingKey) throws IOException; 


(2) Exchange.BindOk exchangeBind (String destination, String 
source, String routingKey, Map<String, Object> arguments) throws 
IOException; 


(3) void exchangeBindNoWait (String destination, String source, 
String routingKey, Map<String, Object> arguments) throws IOException; 


方法 中 的 参数 可 以 参考 3.2.1 节 的 exchangeDeclare 方 法 。 绑 定之 后 ， 
消息 从 source 交 换 器 转发 到 destination 交 换 占 ， 某 种 程度 上 来 说 
destination 交 换 右 可 以 看 作 一 个 队列 。 示 例 代 码 如 代码 清单 3-8 所 示 。 

代码 清单 3-8 

channel.exchangeDeclare ("source", "direct", false, true, null) ; 

channel.exchangeDeclare ("destination", "fanout", false, true, null) ; 

channel.exchangeBind ("destination", "source", "exKey") ; 

channel.queueDeclare ("queue", false, false, true, null) ; 


channel.queueBind ("queue", "destination", "">) ; 


channel.basicPublish C"source", "exKey", null, 
"exToExDemo".getBytes () ) ; 





生产 者 发 送 消 息 至 交换 器 Source 中 ， 交 换 器 source 根据 路 由 键 找 到 
与 其 匹配 的 另 一 个 交换 器 destination， 并 把 消息 转发 到 destination 中 ， 进 
而 存储 在 destination 绑 定 的 队列 queue 中 ， 可 参考 图 3-1。 


name=“destination” 


type="fanout” 
queue 


aa 


Type=“direct” 


图 3-1 交换 器 与 交换 器 绑 定 
3.2.5 何 时 创建 


RabbitMQ 的 消息 存储 在 队列 中 ， 交 换 费 的 使 用 并 不 真正 耗费 服务 
器 的 性 能 ， 而 队列 会 。 如 果 要 衡量 RabbitMQ 当 前 的 QPSD 只 需 看 队列 的 
即 可 。 在 实际 业务 应 用 中 ， 需 要 对 所 创建 的 队列 的 流量 、 内 存 占用 及 网 
卡 占用 有 一 个 清晰 的 认 知 ， 预 估 其 平均 值 和 峰值 ， 以 便 在 固定 人 硬件 资源 
的 情况 下 能 够 进行 合理 有 效 的 分 配 。 

按照 RabbitMQ 官 方 建议 ， 生 产 者 和 消费 者 都 应 该 尝试 创建 (这 里 
指 声 明 操作 〉 队 列 。 这 是 一 个 很 好 的 建议 ， 但 不 适用 于 所 有 的 情况 。 如 
果 业 务 本 刁 在 架构 设计 之 初 已 经 充分 地 预 估 了 队列 的 使 用 情况 ， 完 全 可 
以 在 业务 程序 上 线 之 前 在 服务 器 上 创建 好 《比如 通过 页 面 管 理 、 
RabbitMQ 命 令 或 者 更 好 的 是 从 配置 中 心 下 发 ) ， 这 样 业 务 程 序 也 可 以 
免 去 声明 的 过 程 ， 直 接 使 用 即 可 。 


预先 创建 好 资源 还 有 一 个 好 处 是 ， 可 以 确保 交换 占 和 队列 之 间 正 确 
地 绑 定 匹配 。 很 多 时 候 ， 由 于 人 为 因素 、 代 码 缺 陷 等 ， 发 送 消 妃 的 交换 











器 并 没有 绑 定 任何 队列 ， 那 么 消息 将 会 丢失 ; 或 者 交换 器 绑 定 了 菏 个 队 
列 ， 但 是 发 送 消息 时 的 路 由 键 无 法 与 现存 的 队列 匹配 ， 那 么 消 轧 也 会 丢 
失 。 当 然 可 以 配合 mandatory 参 数 或 者 备份 交换 器 《详细 可 参考 4.17 ) 
来 提高 程序 的 健壮 性 。 

与 此 同时 ， 预 估 好 队列 的 使 用 情况 非常 重要 ， 如 果 在 后 期 运行 过 程 
中 超过 预定 的 阐 值 ， 可 以 根据 实际 情况 对 当前 集群 进行 扩容 或 者 将 相应 
的 队列 迁移 到 其 他 集群 。 迁 移 的 过 程 也 可 以 对 业务 程序 完全 透明 。 此 种 
方法 也 更 有 利于 开发 和 运 维 分 工 ， 便 于 相应 资源 的 管理 。 

如 果 集 群 次 源 充 足 ， 而 即将 使 用 的 队列 所 占用 的 资源 又 在 可 控 的 范 
围 之 内 ， 为 了 增加 业务 程序 的 灵活 性 ， 也 完全 可 以 在 业务 程序 中 声明 队 
列 。 

至 于 是 使 用 预先 分 配 创建 资源 的 静态 方式 还 是 动态 的 创建 方式 ， 需 
要 从 业务 逻辑 本 映 、 公 司 运 维 体系 和 公司 人 硬件 资源 等 方面 考虑 。 











3.3 发送 消 忆 


如 果 要 发 送 一 个 消息 ， 可 以 使 用 Channel 类 的 basicPublish 方 法 ， 比 
如 发 送 一 条 内 容 为 “Hello World! ”的 消息 ， 参 考 如 下 : 


byte[] messageBodyBytes = "Hello, world!".getBytes © ; 





channel.basicPublish (exchangeName, routingKey, null, 
messageBodyBytes ) ; 


为 了 更 好 地 控制 及 送 ， 可 以 使 用 mandatory 这 个 参数 ， 或 者 可 以 发 
送 一 些 特定 属性 的 信息 : 





channel.basicPublish(exchangeName, routingKey, mandatory, 
MessageProperties.PERSISTENT TEXT PLAIN, 
messageBodyBytes) ; 





免费 样 章 到 此 结束 。 





